Setting.exists reflects secure settings but .get doesnt

[tvernum]

Setting.exists is implemented by checking whether the key is in Settings.keySet()
But keySet returns the union of standard settings and secure settings, so this means that a setting is considered to exist if it is in either elasticsearch.yml or elasticsearch.keystore
However Setting.get() does not read secure settings, so code that tries to do

if (setting.exists()) {
  return setting.get();
} else {
 // ...
}

Will do the wrong thing if the setting has been (presumably incorrectly) added to the keystore.

My proposal would be to add a keySet(boolean includeSecureSettings) to Settings, and have exists (in non-secure Setting) call that with false.

[elasticmachine]

Pinging @elastic/es-core-infra

[rjernst]

We have an existing check for secure settings inside elasticsearch.yml. I think we just need the reverse?

Here is the existing error inside SecureSetting:

throw new IllegalArgumentException("Setting [" + getKey() + "] is a secure setting" +
                    " and must be stored inside the Elasticsearch keystore, but was found inside elasticsearch.yml");

[rjernst]

Also, the checks for the existence of settings is very fragile. I originally had only non secure settings showing with Settings.keySet but this caused all kinds of problems. I think this can be done internally within Setting.get, similar to the check I described above within SecureSetting.get.

[tvernum]

We have an existing check for secure settings inside elasticsearch.yml. I think we just need the reverse?

That would work for me, and would help with #41831