perf(mysql): coalesce result-set response into one write to kill 40ms per-query stall

[luthermonson]

Root cause

The MySQL frontend stalled ~44ms on every query that returns a result set while single-OK-packet responses were unaffected. Measured via ePHPm single-node SQLite (PHP PDO, loopback):

op	before
point SELECT	44.01ms p50
INSERT	1.36ms p50

The asymmetry is the tell: an INSERT reply is a single OK packet; a SELECT reply is a multi-packet result set (column-count, one column-def per column, EOF, one packet per row, EOF).

opensrv-mysql writes each of those packets to the socket individually (PacketWriter::end_packet → one write_vectored per packet) and calls flush() only once, after the whole response. On a raw OwnedWriteHalf each packet becomes its own TCP segment. PHP's mysqlnd client does not set TCP_NODELAY, so its Nagle withholds the ACK of the first segment while it waits to coalesce more data to send, and Linux delayed-ACK holds that ACK for ~40ms — deadlocking every result-set round trip.

The server-side set_nodelay(true) added in 54b5fce does not fix this, because the stall is driven by the client's Nagle, not the server's. That's also why it only reproduced through PHP: a client that sets nodelay itself (mysql_async, the mysql CLI) never sees it.

Evidence

• Same litewire frontend, mysql_async client (nodelay on): SELECT 0.42ms, INSERT 0.33ms — no stall, no asymmetry.
• ePHPm PHP PDO client (nodelay off): SELECT 44.0ms, INSERT 1.3ms.
• Protocol-differential probe through ePHPm: both server-side-prepared (binary) and emulated (text COM_QUERY) SELECTs stalled at 44.0ms; only the shape of the response (multi-packet vs single OK) mattered — confirming a response-path Nagle/delayed-ACK deadlock, not a query-send issue.
• 44ms ≈ 40ms Linux delayed-ACK + query time.

(Packet capture inside the WSL2/rootless-podman test host is non-functional for intra-netns loopback, so the root cause was isolated via differential client/protocol experiments rather than tcpdump.)

Fix

Wrap the write half in a BufWriter. opensrv's single trailing flush() now emits the entire result set as one write → one TCP segment, so there is no intermediate packet for the client to sit on. The handshake greeting and every command response are already flushed at their protocol boundaries, so this changes only how many segments a response spans, not protocol semantics. Responses larger than the buffer still flush in chunks (correct, and not subject to the deadlock since the client is actively draining).

Postgres uses pgwire's buffered Framed writer and TDS is a placeholder, so no change is needed there. The existing set_nodelay stays as a correct complementary optimization.

Measured result (rebuilt ePHPm image, same bench)

op	before	after
point SELECT (select_hot)	44.01ms p50	0.23ms p50
select_spread	~44ms p50	0.25ms p50
INSERT	1.36ms p50	0.30ms p50

~177x faster on the point-SELECT hot path; sub-millisecond as required. All 23 mysql_e2e tests pass; cargo fmt --all --check and cargo clippy --workspace --all-targets -- -D warnings are clean.