feat: add GroupColumn support for List / Struct / Map / FixedSizeList in multi-column GROUP BY

[zhuqi-lucas]

Is your feature request related to a problem or challenge?

When a GROUP BY includes any column with a nested type (List, LargeList, FixedSizeList, Struct, Map), multi_group_by::supported_type returns false for that column and the whole grouping falls back to the byte-encoded GroupValuesRows path via arrow_row::Rows, even if every other column would be supported by GroupValuesColumn. Today's supported_type (source):

fn supported_type(data_type: &DataType) -> bool {
    matches!(*data_type,
        DataType::Int8 | Int16 | ... | Float64
        | Decimal128(_, _)
        | Utf8 | LargeUtf8 | Utf8View
        | Binary | LargeBinary | BinaryView
        | Date32 | Date64 | Time32(_) | Timestamp(_, _)
        | Boolean
    )
}

Impact

A wide multi-column GROUP BY where most columns are individually supported by GroupValuesColumn (Utf8 / Date / Boolean / Float) but one column is a nested type (e.g. LargeList<Struct<...>>) is forced onto the slow arrow_row::Rows path. Group key memory grows materially compared to the equivalent column-format storage, and per-group comparisons become byte-by-byte rather than vectorized.

Describe the solution you'd like

Add GroupColumn implementations for the missing nested types and extend supported_type accordingly. Equality is well-defined by Arrow's make_equal-style comparators; hashing of nested values has existing arrow utilities.

Suggested incremental order, easiest first:

1. FixedSizeList<T> where T is a GroupColumn-supported primitive (fixed-width per row, simplest)
2. List<T> and LargeList<T> with primitive child (variable-length, single offset buffer)
3. Struct<...> with all fields being GroupColumn-supported (composition of existing columns under a single null mask)
4. Map<K, V> (most complex due to entry ordering semantics)

Each can be its own PR. The existing arrow_row::Rows path remains the fallback for any nested type not yet supported, so this is purely an optimization.

Describe alternatives you've considered

• arrow_row fallback (current state): correct, but significantly more memory and CPU than GroupValuesColumn when the grouping mostly consists of cheap columns and the nested column is one of many.
• Avoid grouping by the nested column at the SQL level: works case-by-case (e.g. wrap in ANY_VALUE) but does not help when the nested column is the legitimate group key.

Additional context

Issue #22526 is a separate, related pathology on the emit side. This issue is about the input/intern side (which GroupValues impl is selected). The two are independent and can land in either order.

[zhuqi-lucas]

Cross-link: opened #22701 proposing a generic FallbackGroupColumn approach as a complementary direction.

The two issues address the same problem from different angles:

• This issue (feat: add GroupColumn support for List / Struct / Map / FixedSizeList in multi-column GROUP BY #22682): add type-specific specializations (List / LargeList / FixedSizeList / Struct / Map). Each gives a fast column-wise + short-circuit path for that exact type.
• feat: add generic FallbackGroupColumn so any Arrow type uses GroupValuesColumn (no fallback to GroupValuesRows) #22701: add a generic fallback so any Arrow type goes through GroupValuesColumn, with the specializations from this issue (and the existing primitive / byte / boolean / decimal128 ones) layered on top as opt-in optimizations.

Together they solve both:

1. The structural lock-in where a single unsupported column drags otherwise-fast-path-eligible columns onto GroupValuesRows (addressed by feat: add generic FallbackGroupColumn so any Arrow type uses GroupValuesColumn (no fallback to GroupValuesRows) #22701).
2. The per-type performance ceiling once you are already on GroupValuesColumn (addressed by the specializations here).

Happy to start with whichever direction maintainers prefer to land first. If #22701 lands, the specializations here become straight perf wins without affecting correctness fallback; if this issue lands first, #22701 becomes a follow-up that catches everything else.

[zhuqi-lucas]

PR ready for review: #22706

[zhuqi-lucas]

This issue is now tracked as part of the broader EPIC #22715, which covers both the nested types here and the remaining primitive types (FixedSizeBinary / Float16 / Duration / Interval / Decimal256 / Dictionary).