Add validate_group_by_all_key_types to gate the GROUP BY ALL key type validation - #119868

…type validation

`GROUP BY ALL` adds the `SELECT` expressions as grouping keys in `expandGroupByAll`, which
runs after `resolveGroupByNode` has already done its tuple unwrapping and key type
validation for an explicit `GROUP BY`. The keys `GROUP BY ALL` expands into therefore went
through neither, until ClickHouse#110206 re-ran both on them: `expandTuplesInList`, which fixes
ClickHouse#83433, and a `validateGroupByKeyType` loop. That loop is an acceptance rule, and it
changed behavior: a `Variant`/`Dynamic` grouping key written as `GROUP BY ALL`, typically an
untyped JSON subpath, is rejected with `ILLEGAL_COLUMN` from 26.7 onward where earlier
versions accepted it.

The tightening is intended, so this keeps it as the default and only makes it reachable by
`compatibility`. Reported in ClickHouse#119852 with a measured upgrade break (3 of 20 sampled
chReplay instances) and an identical result hash once the key was permitted, i.e. the old
acceptance computed correct answers rather than wrong ones; without a gate an upgrade
breaks those queries with no way to keep them running short of rewriting them or enabling
`allow_suspicious_types_in_group_by`, which also loosens the explicit `GROUP BY` and
`ORDER BY` checks.

The setting is read at the two call sites rather than inside `DB::validateGroupByKeyType`:
that helper is shared with the explicit `GROUP BY`, `GROUP BY GROUPING SETS`, the window
`PARTITION BY` and both old-analyzer sites, none of which changed behavior, so gating the
helper would newly loosen all of them.

Two call sites, not one, because `GROUP BY ALL` reaches the validation two ways. Normally
the late `was_group_by_all` block validates. But when `scope.group_by_use_nulls` is set,
which needs `group_by_use_nulls` plus a `WITH ROLLUP`/`CUBE`/`GROUPING SETS` modifier,
`GROUP BY ALL` is expanded early and `expandGroupByAll` clears the flag, so that block is
skipped and `resolveGroupByNode` validates the expanded keys instead. Hence the ALL-ness is
captured once before any expansion and threaded in as a policy; an explicit `GROUP BY`
passes `true` and is bit-for-bit unchanged. The `nullable_group_by_keys` collection sharing
those loops stays outside the guard: it implements `group_by_use_nulls` promotion, which the
setting must not affect, and moving it inside would reintroduce the bug fixed in
b3edb0b.

The history entry goes in the 26.7 block, not 26.8. ClickHouse#110206 (9d67075) merged 2026-07-16,
inside the 26.7 development window, and `gh api .../compare/v26.7.1.1315-stable...9d67075`
reports `behind`, so the rejection first shipped in 26.7; recording it under 26.8 would tell
`compatibility` that 26.7 accepted such a key, which it did not. The second entry in the
current 26.9 block is required by
`ci/jobs/check_style.py::check_settings_changes_history`, which demands every added setting
under the current version block whenever another `src/` file changes.

Closes: ClickHouse#119852

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>