distsql: tracking issue for feature parity gaps

[RaduBerinde]

There are certain queries which either can't run at all in distsql, or which we never run in distsql because they can be much less efficient. Closing on these gaps is a pre-requisite to unifying the two SQL execution paths.

• support tuples in streams (distsql: support tuples in streams #15938)
• support ordinality node
• support internal tables (e.g. TRACE)
• support SHOW TRACE FOR (distsql: make SHOW TRACE FOR work with distsql #16562)
• support ARRAY_AGG (distsql: support ARRAY_AGG in distsql #15939)
• support set operations (distsql: Set operations (UNION, INTERSECT, EXCEPT) #10432)
• more efficient limits (RFC)
• support subqueries
• support distsql operations in a write txn (distsql: TxnCoordSender doesn't allow distribution if transaction changed data #13376)
• support writing to tables (from the gateway node) using results from a distsql query
• support window functions (distsql: support window functions in distsql #24425)
• support spool
• support batching (at least for mutations)

We also have a bunch of planNodes which implement various internal statements: split, scatter, set cluster settings, cancel query, show ranges, alter table, copy from, etc. These are all written in the local SQL framework and would need some kind of refactoring.

I'm likely missing a few so please add more if you think of anything. CC @andreimatei @knz @petermattis @vivekmenezes

[petermattis]

Cc @awoods187

[jordanlewis]

Closing this. I don't think it's useful anymore.