Deserialize dimensions in group by queries to their respective types when reading from their serialized format

[LakshSingla]

Description

Grouping on complex columns allowed the dimensions to be of complex types. When reading the dimensions from their serialized format, we must deserialize them in their desired complex type. Otherwise, Druid deserializes the dimension into a generic java object equivalent to objectMapper.readValue(serializedValue, Object.class)

We read the dimensions from their serialized form when reading dimensions over the wire (in native queries)

This wasn't discovered at the time of the original PR because only JSON columns support groupability at the moment, and they are designed to handle the generic Java object that the object mapper deserializes to by default. However, this is required for most other complex types that require groupability.

Interface change

public interface TypeStrategy<T> extends Comparator<Object>, Hash.Strategy<T>
{
...
  default Class<?> complexDimensionType()
  {
     // To be implemented by any type supporting groupability
     // Throws exception by default
  }
} 

Benchmarking - I have ran the GroupByBenchmark.queryMultiQueryableIndexWithSerde benchmark with limited iterations and here are the results before and after the change.

With changes, + array
Benchmark                                           (initialBuckets)  (numProcessingThreads)  (numSegments)  (queryGranularity)  (rowsPerSegment)  (schemaAndQuery)  (vectorize)  Mode  Cnt       Score       Error  Units
GroupByBenchmark.queryMultiQueryableIndexWithSerde                -1                       2              4                 all            100000           basic.A        force  avgt    6  183664.081 ± 18777.234  us/op

Without changes + array
Benchmark                                           (initialBuckets)  (numProcessingThreads)  (numSegments)  (queryGranularity)  (rowsPerSegment)  (schemaAndQuery)  (vectorize)  Mode  Cnt       Score       Error  Units
GroupByBenchmark.queryMultiQueryableIndexWithSerde                -1                       2              4                 all            100000           basic.A        force  avgt    6  184934.791 ± 18924.516  us/op

~

Release note

(none)

---

Key changed/added classes in this PR

• MyFoo
• OurBar
• TheirBaz

---

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[clintropolis]

nit: maybe getComplexClass or the classic getClazz would be a better name since it probably isn't a different type when used as a dimension (and we have the separate groupable to determine if it can be used as a dimension or not)

[clintropolis]

should this just use getClazz of ObjectStrategy?

[clintropolis]

should jsonMapper and spillMapper be different? I know spillMapper is usually smile, though isn't results from historicals also smile? regardless, probably worth a comment somewhere of why we have different mappers

[LakshSingla]

When writing the code, this seemed natural, since we are using spillMapper for the spilling runner, and nothing else. After going through the group by code again, I think we should still be using the jsonMapper.
The input rows which get further deserialized according to the complex types are sourced from:

1. https://github.com/apache/druid/blob/master/processing/src/main/java/org/apache/druid/query/groupby/epinephelinae/GroupByRowProcessor.java#L90 - The input rows are from the processed subqueries.
2. https://github.com/apache/druid/blob/master/processing/src/main/java/org/apache/druid/query/groupby/epinephelinae/GroupByMergingQueryRunner.java#L254C54-L254C55 - The input rows are to the mergeRunner, which has already been read from the segments by the createRunner.

[LakshSingla]

Retested stuff, serde in (2) is not required.

[LakshSingla]

Thanks for the review @clintropolis @asdf2014