Tribe Node fails to start with secure settings for xpack.security

[tvernum]

If a node is configured as a tribe node, then we automatically copy each xpack.security.* setting from the root settings, to each of the tribe client settings (Security.addTribeSettings)

However, that fails if the xpack.security setting is a SecureSetting as Settings.Builder.copy cannot copy secure settings.
The error is a somewhat cryptic

Caused by: java.lang.IllegalArgumentException: source key not found in the source settings

Given Tribe is deprecated in 6.x and removed in 7, we don't want to do much here, but we don't want a situation where nodes fail to start, and the errors are unclear.

Possible solutions:

1. Don't allow secure settings for xpack.security.* on tribe nodes. That is, in addTribeSettings fail if we find a secure setting (with a reasonable error message)
2. Check & require that the tribe.xyz.xpack.security.* secure setting already exist in the keystore. That is if, xpack.security.transport.ssl.keystore.secure_password exists in the keystore, require that tribe.xyz.xpack.security.transport.ssl.keystore.secure_password also exist, and fail with a reasonble error message if it does not.

[elasticmachine]

Pinging @elastic/es-security

[elasticmachine]

Pinging @elastic/es-core-infra

[jasontedor]

We discussed this during the core/infra weekly meeting today and we have agreement that we are not going to address this issue. We feel this is justified because:

• the tribe node is deprecated and already removed from the codebase for 7.0.0
• it appears that configuring a tribe node in this way has not worked since the settings in question were made secure settings this doesn't qualify as regression

As such, we feel the only change here should be making the error message clearer.