Bug Report: stored-procedure session state persists on a transaction connection recycled at commit

(see above)

Related

This is one of a set of changes that came out of one investigation into what a stored procedure, or any statement whose tables the planner never sees, can do on a vttablet. They reference each other so the whole picture is reachable from any one of them.

Table ACL — GHSA-w6mx-2f8x-pqf4

• #21053 — fail closed under strict table ACL for statements whose tables the parser discards (DO, CALL, REPAIR, OPTIMIZE, LOAD DATA)
• #21139 — stacked on #21053: check the reads embedded in statements the planner does parse (CREATE TABLE ... AS SELECT, EXPLAIN ANALYZE, SHOW ... WHERE, SET), reject connection settings that carry a subquery, and have a targeted vtgate session store a SET's value rather than its expression
• #21134 — still open: a stored function invoked inside an expression runs its body outside the table ACL
• #21138 — still open: parse the CREATE TABLE source forms the grammar only partially accepts, which #21139 has to deny outright today
• #21140 — still open: ALTER/REVERT VITESS_MIGRATION derive no permissions, so any authenticated caller can control Online DDL migrations; split out of #21053's review

Stored-procedure session residue

• #21046 — procedure-body session state (SET SESSION, temp tables) persists on pooled connections after CALL
• #21062 — fixes #21046 by discarding the pooled connection after CALL
• #21063 — (this issue) still open: the same residue on a transaction connection recycled at commit
• #21066 — still open: the pooled-connection baseline differs between fresh and settings-reset connections on servers using init_connect