Pinging @elastic/es-data-management (Team:Data Management)

As suggested by @dakrone, I’ll look into using custom index metadata instead of a private setting for my use case. If that approach works out well, I’ll probably enhance the settings provider interface so that it can provide custom index metadata when an index is created or updated.

@dakrone thanks again for the suggestion. I've prototyped the approach in the context of #132566 and I like it lot better compared to the private index setting. It also avoids having to add infrastructure to allow providing private index settings when they're system-provided.

I was also considering whether to expose the full IndexMetadata.Builder to IndexSettingProvider and use a real index metadata field rather than custom metadata. But that seems more controversial as it makes the IndexSettingProvider more powerful than it needs to be which makes it harder to reason about failure domains. For example, it could then directly add index settings, bypassing some of the validation that we're doing today agains the returned index settings. Also, it would require to adjust the serialization logic.

I admit it's a bit weird that the class called IndexSettingProvider can now effectively also provide custom metadata. Maybe we could think about a new name but maybe it's also fine to live with that slight cognitive dissonance. I've also considered creating a new interface, or at least new methods that return a custom metadata map. However, the logic in #132566 needs to set the dimensions either as an index.routing_path setting, or as a custom metadata, depending on whether the path matches all potential dimension fields. So splitting this into two methods would be very awkward.

I don't love that we have both a return value and a passed in builder. I am on the fence about switching it to return void and instead passing in both the map builder and settings builder.

I don't like it either. I gave it a shot and make the refactoring. It's a lot better IMO. It's mostly mechanical changes that IntelliJ could assist me with. I also think it simplifies the control flow of existing implementations like LogsdbIndexModeSettingsProvider#getAdditionalIndexSettings.

I also wish we had a builder that was collection-compatible instead of using ImmutableOpenMap (though I understand why you used it).

I've changed it to a BiConsumer<String, Map<String, String>> now and I like it a little better.

I've reverted the changes to server/src/main/java/org/elasticsearch/common/settings, removing core-infra as reviewer.