Text fields incorrectly fallback to source in block loader for logsdb indices

[Kubik42]

When index mode is logsdb, and there is a keyword multi field with ignore_above execluded, text fields incorrectly fallback to using source for loading data blocks.

LogsDB indices have a different default value for ignore_above. This value is not taken into account when the following block is evaluated since canUseSyntheticSourceDelegateForLoading() only checks Integer.MAX_VALUE.

As a result, in logsdb indices, when a keyword multi field is present with ignore_above excluded, we incorrectly load text data from source (synthetic or not) rather than directly from stored fields. I don't have the numbers yet, but I imagine that this is quite slow.

[elasticsearchmachine]

Pinging @elastic/es-storage-engine (Team:StorageEngine)

[martijnvg]

Yes, this is a performance issue that we in general didn't address. If ignored above is configured in this configuration (text field as parent and keyword as multi-field) then typically most documents will store the values in a doc value fields. However if a value's length exceed the configured ignore above of the keyword multi-field then it gets stored in a stored field. In order to read correctly in this case we would need to first try load from doc values and if it is missing check the stored field containing ignored values and only if it isn't in stored field a null value should used. This block loading logic doesn't exist today.

So today when ignored above is configured, block loading falls back to loading from _source (given that before hand it doesn't know whether values are in doc values or stored fields). This ensures the block loading functions correctly. In case of synthetic source this means synthesizing the source and then just fetching the parent from _source. This is expensive, but I think this can be improved.

[Kubik42]

Fixed in #134253