[data.search.aggs] Support string statistics aggs in AggConfigs

[wylieconlon]

On the ES side this was recently merged: elastic/elasticsearch#47468

a new metric aggregation called string_stats that operates on string terms of a document and returns the following:

min_length: The length of the shortest term
max_length: The length of the longest term
avg_length: The average length of all terms
distribution: The probability distribution of all characters appearing in all terms
entropy: The total Shannon entropy value calculated for all terms

This could be integrated into the Kibana aggregation configs, similar to the std_deviation metric which is implemented using extended_stats.

Based on the docs for the new aggregation these are all numbers except the multi-value distribution, so any of these numbers except distribution could be used as a metric in a visualization.

• add new agg type
  • create the agg type
  • export an interface for the agg type's params
  • update AggParamsMapping in types.ts
  • register agg type via agg_types.ts
  • unit tests
• add agg type expression function
  • write the expression function
  • register expression function via agg_types.ts
  • unit tests

Part of #60126

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[timroes]

@wylieconlon Do we have a use-case for that in Lens right now? So does it make sense adding it to AggConfigs already without adding vis editor config, or do you suggest we're also adding this directly to an editor (like the old vis editor) to the user to configure?

[wylieconlon]

Two use cases I imagine:

• This is an introspection feature like Cardinality and helps users understand the size and shape of their data. It makes sense to build it into vis editors.
• Metadata for determining if a keyword is something we want to recommend- super-long keywords are not good for visualizing. This does not require the agg config

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[ppisljar]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.