Add deprecation warning for default value of action.destructive_requires_name

[williamrandolph]

When we merge #66908, we need to add a breaking change warning for 7.x users who may be relying on the old default of the setting.

We're not deprecating the setting as a whole, just the old default value, but since we don't want anyone to be caught by surprise with this change, it seems appropriate to use the deprecation logger.

Relates #67543

[elasticmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[rjernst]

Thanks William. I left a couple comments. Also, could we have some unit tests for the deprecation in DestructiveOperationsTests?

[rjernst]

Since the setting is updatable, can't this get out of sync?

[williamrandolph]

This is a little bit tricky, and I'm not sure how to address it. The DestructiveOperations object only has access to settings and clusterSettings at construction time, and there it sets up a listener for changes. That listener operates on a value for the setting, and doesn't know whether the value is pulled from the default or was explicitly provided. I've added a line to the callback that sets this value to true on any update to the action.destructive_requires_name property, so that form that point on we won't see deprecation warnings.

I think there are three options:

1. What I've done here, which ought to log a warning up to the point where the setting is explicitly updated and not at all thereafter.
2. Change the setting updater functions so that they can compare more than just values. (This seems very intrusive.)
3. Update or override the Setting#checkDeprecation method to log a deprecation warning when retrieving the new value from the raw settings.

I will take a look at doing 3 to see if it works.

[williamrandolph]

It doesn't look like 3 will be straightforward either, unless we make changes to Setting.

[rjernst]

There is an alternate settings update consumer method that may work. That is, instead of passing a consumer which takes in the value, there is a consumer which takes the entire settings object, but is only called when a fixed list of settings changes, in this case the one setting we care about. Then exists can be called on the settings object to determine whether this is set. Take a look at addSettingsUpdateConsumer(Consumer<Settings> consumer, List<? extends Setting<?>> settings)

[williamrandolph]

Works like a charm. Thank you for the help.

[rjernst]

LGTM