security(pipes): SET/USE/EXECUTE AS in a pipe leak into the pooled session

[EricAndrechek]

Area: pipes · security

A pipe runs its SQL on one of the tenant's pooled native connections. With the native protocol, each connection is a ClickHouse session. So a pipe whose statement changes session state changes it for whatever runs on that pooled connection next:

• SET <setting> = <value> changes a setting for later queries on that connection, such as max_execution_time, readonly or max_result_rows.
• USE <db> changes the default database.
• A bare EXECUTE AS <user>, with no statement after it, switches the session's user. With fix(pipes): run write pipes every call, uncached and uncoalesced #634 this is classified as a write and runs through Exec. It was measured to take effect: Exec returns nil.

SET and USE were already classified as writes and run through Exec before #634. The bare EXECUTE AS case was measured on ClickHouse 26.6.3.62. That SET and USE carry over to the next query on the pooled connection is inferred from ClickHouse's native session semantics, and is untested here.

Impact: a pipe author (an operator) can change the settings, the database or even the user for later requests that happen to reuse the connection. That includes structured queries, whose policy limits can be undone by a SET. The effect lasts until the connection is recycled.

Proposal: refuse session-state statements (SET, USE, EXECUTE AS with no statement after it, and probably SET ROLE / SET DEFAULT ROLE) in a pipe definition when it is loaded or put. Alternatively, run pipes on connections whose session state is reset after each use. Related: #634, #666.