sql: preserve explicit ROW constructors during tuple flattening

[Alignyx]

Summary

Fixes #173264.

Explicit ROW constructors are scalar composite expressions, but clause tuple flattening treated them like syntactic parenthesized expression lists. This caused two incorrect GROUP BY behaviors:

• GROUP BY ROW() on empty input became an empty grouping set, selected scalar aggregation, and returned one row containing count 0 instead of returning no groups.
• GROUP BY ROW(a, b) exposed a and b as individual grouping columns, so ungrouped references to either field were incorrectly accepted.

Syntactic lists such as GROUP BY (a, b) still need to flatten recursively, so the fix must retain the parser distinction between those lists and explicit ROW constructors.

Root cause

The parser already records this distinction in tree.Tuple.Row: explicit ROW(...) syntax sets Row to true, while a parenthesized list leaves it false.

After type resolution, optbuilder calls flattenTuples while expanding GROUP BY and related clause expression lists. Both flattenTuples and its recursive helper previously expanded every tree.Tuple without consulting Row. Consequently:

• ROW() contributed zero grouping expressions and buildGrouping constructed a scalar-group-by operator with cardinality [1-1].
• ROW(a, b) contributed two independent grouping expressions, incorrectly registering both child columns as grouped.

The semantic distinction was therefore lost during optbuilder clause expansion, before physical planning or aggregate execution.

Fix

Tuple flattening now checks Tuple.Row at both the top-level and recursive boundaries:

• Parenthesized expression lists continue to flatten recursively.
• Explicit ROW constructors remain a single scalar expression, including when nested inside a parenthesized list.
• The Tuple.Row field documentation now records its clause-expansion responsibility.

Because the helper is shared by GROUP BY, statement ORDER BY, aggregate-internal ORDER BY, and window PARTITION BY / ORDER BY processing, this preserves the same explicit-ROW boundary consistently across all callers.

Tests

Added a regression subtest covering:

• Empty-input GROUP BY ROW() versus the true empty grouping set GROUP BY ().
• GROUP BY ROW(a, b) rejecting an ungrouped child reference with SQLSTATE 42803.
• A nested explicit ROW inside a parenthesized grouping list.
• Continued recursive flattening of syntactic parenthesized lists.
• Valid grouping and projection of the complete composite key.

Validation included the regression in all 12 applicable logic-test configurations, the complete local aggregate logic file, and the full optbuilder data-driven test suite.

Release note (bug fix): GROUP BY now treats explicit ROW(...) constructors as single composite grouping expressions.

[blathers-crl]

Thank you for contributing to CockroachDB. Please ensure you have followed the guidelines for creating a PR.

My owl senses detect your PR is good for review. Please keep an eye out for any test failures in CI.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}