Improving performance of get data streams API by avoiding getting effective mappings

[masseyke]

The get data streams API needs the data stream's settings in order to get information about ILM and the index mode. It calls MetadataDataStreamsService::getEffectiveSettings to do this, which is correct. However, that method is fairly expensive because it calls getEffectiveMappings so that it can call addSettingsFromIndexSettingProviders with the correct mappings. We don't need any of the information from these index settings providers for ILM or the index mode. Since the get data streams API can be called for all data streams, we call this slow method hundreds or thousands of times, and the API can take so long to return that kibana gives up on it.
This PR removes the call to getEffectiveSettings, and instead just gathers the settings from the template, along with data stream settings overrides.
This was caused by #137407

[elasticsearchmachine]

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

[elasticsearchmachine]

Hi @masseyke, I've created a changelog YAML for you.

[dakrone]

LGTM, I left one comment, thanks for fixing this.

[dakrone]

I think this makes sense. Can we also add something like:

assert settings.equals(metadataDataStreamsSettingsService.getEffectiveSettings(state.metadata(), dataStream)) : "these should always match etc etc";

after this line, so that if we ever encountered a situation where a provider changed the settings, then we would fail tests? That way we only pay the cost when asserts are enabled.

[masseyke]

I don't think that that assertion would work, b/c the providers do change some of the settings.

[nielsbauman]

the index mode, neither of which come from additional settings
Comment providers.

I don't think that is true; LogsdbIndexModeSettingsProvider seems to supply an index mode:

elasticsearch/x-pack/plugin/logsdb/src/main/java/org/elasticsearch/xpack/logsdb/LogsdbIndexModeSettingsProvider.java

Line 133 in 4c33d20

additionalSettings.put(IndexSettings.MODE.getKey(), IndexMode.LOGSDB.getName());

Or am I misreading something?

[masseyke]

Oh good catch. That complicates things.

[masseyke]

I'm thinking then that I'll still call getEffectiveSettings, but a new variant that lets you skip merging all the mappings.

[masseyke]

Oh, actually that next line that calls resolveMode actually applies all of the additional settings providers and we get the correct mode anyway. I'll add a test that shows that.

[elasticsearchmachine]

💚 Backport successful

Status	Branch	Result
✅	9.2