Separation of Concerns in DocValueFormat

[not-napoleon]

FieldType defines a method docValueFormat(String format, ZoneId timezone) which specific field types can override to provide support for formatters in aggregations. The resulting DocValueFormat, however, has multiple meanings which are sometimes incompatible. There are at least three different ways in which this formatter is used:

• Parsing string values from the user supplied missing parameter
• Formatting the key (i.e. bucket id) on bucket aggregations
• Formatting the value on metric aggregations

There may be other, as yet unidentified, roles this formatter is being used for.

This creates a number of challenges, most notably when the input type and output type of an aggregation differ, as the same formatter will not make sense for both the input and the output. Most aggregations to this point have not encountered this issue because the input and output types line up, but as we try to expand aggregation support to more field types, that will stop being true. Especially after the planned values source refactor (see #42949), which will enable dynamically registering type support for aggregations, relying on inputs and outputs using the same format breaks down.

Please use this issue to discuss possible solutions and record issues we are running into with the current implementation.

[elasticmachine]

Pinging @elastic/es-analytics-geo (:Analytics/Aggregations)

[not-napoleon]

As per conversation with @jpountz , while we want to split this out for aggregations, we don't want to make a change at the field mapping level.

[jtibshirani]

Adding another use of docvalues formats for context: they're used to format docvalues_fields in the search response. It's easy to forget this use case and we have some related bugs (#53246, #55993).