[TSVB] Improve dashboard performance

[alexwizp]

Summary

In #82964 we added a functionality to communicate TSVB index-patterns to dashboard.
Since in version 7.12 TSVB worked only with string indices, we had to use the find method from the data plugin.
This solution works fine, but slow - the reason the find method works without caching = (

Here I should highlight that in some cases this method returns more than one index and for each of them the fields list are requested.

Not let's try to emulate this situation:

1. Install 3 data sets and create new TSVB visualization
2. Go to Panel Options and turn off Kibana index Patterns mode
3. Fill kibana_sample* as an index, @timestamp as a time field and save your visualization
4. Create a new Dashboard and add saved visualization more than 40 times

Result:
44 separate requests for fields

My suggestion.

1. Due to the fact that now we have a new mode ([TSVB] Enable dual mode, support index patterns and strings #92812) for selecting index patterns in TSVB, we probably don't need to execute that logic for strings indexes.

How example above works for string indices with my changes:

The same for activated Kibana Index Pattern mode (kibana_sample* Kibana index was created):

[stratoula]

Alex thanx for this PR. I have the following questions:

• With that PR, we stop supporting the TSVB's communication of the index patterns to the dashboard. This means that we "take back" a bug fix that we fixed some minors ago.
• If I understand correctly, the find method works only for string mode. Right? If the user creates a TSVB visualization with the index pattern mode, then we don't have performance issues. So. in my understanding, this is a very good reason for our users to switch to index pattern mode.

[alexwizp]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: f803c1e
• Storybooks Preview

Metrics [docs]

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
visTypeTimeseries	110.2KB	110.2KB	-5.0B

History

• 💔 Build #120300 failed df721d6
• 💔 Build #120288 failed dab1e4e

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[wylieconlon]

I tested this PR on the large TSVB-heavy dashboard that I've been testing all the changes with, which uses strings to define the index patterns, and it appears that this PR has a smaller performance impact than I can test locally.

I do see that there are fewer requests to the find endpoint than before, but it appears that this was not a big part of the overall dashboard loading time. The biggest factors seem to be the ones that I already identified:

• Schema validation
• KQL performance
• Improved caching

For some rough idea, I was seeing a range of 15 seconds +/- 0.5s to load my dashboard on master vs master with these changes.