tokio-postgres: fix deadlock in query_typed/prepare on unknown OIDs (per-response parking variant — alternative to #1348) - #1349

Summary

This is an alternative to #1348 for the same deadlock. Same root
cause, different remediation. The two PRs are mutually exclusive — pick
whichever you prefer; closing the other.

The deadlock is described in detail in #1348 and reproduced minimally
here: https://github.com/rubenfiszel/tokio-postgres-deadlock-repro
TL;DR: query::query_typed calls get_type(client, oid).await
synchronously while still holding the streaming Responses; on a
result schema with unknown OIDs (citext, custom enums / domains,
postgis geometry, …) the original query's DataRows back up in the
per-Responses mpsc::channel(1), Connection::poll_read stops
draining the wire, and the typeinfo sub-query response (queued behind
those DataRows on the same socket) never arrives.

Approach (vs. #1348)

This PR keeps the mpsc::channel(1) per Responses and instead changes
Connection::poll_read to keep draining the wire when a sender backs up
— parking the unsent frame on a per-response queue inside Response
itself. New wire frames are routed to target_response_idx() — the
first in-flight response whose ReadyForQuery hasn't been observed yet
— so a congested streaming query no longer blocks delivery to a
concurrent typeinfo sub-query whose response is queued behind it on the
same socket.

Why per-response (and not a single global parked queue)

A single global queue still deadlocks: once response[0]'s sender is
full, the global queue accumulates frames for response[1] that we
have no way to deliver without first delivering response[0]'s
frames. Per-response queues let us poll each sender independently in
drain_all_parked.

The completion_seen flag

Response::completion_seen tracks whether the ReadyForQuery frame
for that response has been observed on the wire — independent of
whether it's been delivered to the consumer's channel yet.
target_response_idx() uses this to route subsequent wire frames to
the next response while the completion frame for the previous one is
still flushed in-order to its own consumer when its sender unblocks.

Reproduction

git clone https://github.com/rubenfiszel/tokio-postgres-deadlock-repro
cd tokio-postgres-deadlock-repro
./setup.sh
# Test against master (deadlocks at limit ~100+):
cargo run --release
# Test against this PR (passes at all limits):
# edit Cargo.toml [patch.crates-io] to point at this branch
cargo run --release

master:

[limit 100]  ok (100 rows) in 663µs
[limit 200]  TIMEOUT after 10s
[limit 500]  TIMEOUT after 10s

with this PR:

[limit 100]  ok (100 rows) in 761µs
[limit 200]  ok (200 rows) in 1.5ms
[limit 500]  ok (500 rows) in 898µs

Test plan

• cargo build -p tokio-postgres clean
• cargo test -p tokio-postgres --lib passes
• Standalone repro: passes at all LIMITs (deadlocks at 100+ on
  master)
• End-to-end against a real workload (the same query_typed_raw
  call against a partitioned table with a citext column on Neon)
  that this PR's author originally hit — hangs indefinitely on
  master, completes in ~420ms with this patch

Why two PRs

#1348 is the minimal fix (one type swap). This PR preserves the
bounded-channel API at the cost of ~100 lines of routing bookkeeping.
Functionally and memory-wise they're equivalent. I have a slight
preference for #1348 for the obvious reason (smaller surface), but
opened both so you can pick based on whether the bounded-vs-unbounded
distinction matters to you for some reason I might not be aware of.