ESQL: unused union type attributes can use a lot of memory

[alex-spies]

Relates #107330

In simple queries like FROM logs-* | LIMIT 10, many indices and fields can be involved. In particular, fields mapped to different types in different indices are just passed through, even though we do nothing with them (their values are always null).

Multi-typed fields internally create attributes which contain an error message string with the different types they're mapped to in different indices, e.g. line 1:32: Cannot use field [some_field] due to ambiguities being mapped as [2] incompatible types: [double] in [logs-1, logs-2, logs-3], [float] in [logs-4]. (More specifically: When multi-typed fields are passed through, they get internally represented as UnsupportedAttributes, whose error message is constructed from InvalidMappedFields here.)

These messages can get long; additionally, they get serialized as part of their respective attributes and are being sent to data nodes, although we likely do not need the error string in the data nodes.

Let's reduce that overhead during planning and when serializing the plan.

[alex-spies]

Ideas that we can try:

• Limit the maximum number of indices mentioned in the error message, e.g. Cannot use field [some_field] due to ambiguities being mapped as [2] incompatible types: [double] in [logs-1, logs-2, logs-3] and [32] other indices, [float] in [logs-4, logs-5, logs-6] and [17] other indices.
• Check if we can strip the error message before sending the UnsupportedAttributes to data nodes; the error message should be irrelevant after the validation step.
• Maybe check if we can save some more memory by computing the error message on demand rather than storing it fully expanded; for unsupported types, UnsupportedAttribute alread has the errorMessage method, but we still eagerly instantiate the error message on construction.

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[luigidellaquila]

Unfortunately we cannot easily compute the error message afterwards, as we don't preserve the InvalidMappedField that contains all the information (and anyway, transferring the InvalidMappedField would be quite expensive as well).

Probably the best solution is the first one you proposed, ie. reduce the size of the error message.

Stripping the message completely could be an option as well; the data node does not need it. Anyway, for debug reasons and for consistency, I'd prefer to keep the deserialized versions as similar as possible to the original.