Use read_exact in test_connect_uds

[ShanireZ]

Fixes #967.

connectors::tests::test_connect_uds read the mock server's 9-byte response with
AsyncReadExt::read and discarded the returned length, so a segmented delivery left
buf holding a partial message padded with zeros and the assertion failed. Stream
sockets are free to split a write_all across reads, so this was a latent flake.

The fix is one line: read_exact instead of read.

How it was verified

The flake was made deterministic rather than chased with repeated runs. Having the mock
server split its write into 1 byte + 20ms + 8 bytes — legal stream behaviour, not
sabotage — makes the test fail every time before the change and pass after it. That
perturbation is a reproduction aid only and is not part of this commit.

	no perturbation	perturbed
main @ 0046038	passes (flaky in the wild)	fails 3/3, left: [105, 0, 0, 0, 0, 0, 0, 0, 0]
with this patch	passes 5/5	passes 5/5

105 is i — only the first byte had arrived.

Gates

Run on main @ 0046038, in a Debian 13 container with rustc 1.97.1, before and after
the patch:

gate	result
cargo fmt --all -- --check	pass
cargo check --workspace	pass
cargo clippy --all-targets --all -- --allow=unknown-lints --deny=warnings	pass
cargo test -p pingora-core --lib --features rustls --no-fail-fast	572 passed / 1 failed / 2 ignored, identical set before and after

The one failure (connectors::l4::tests::test_bind_to_port_range_on_connect) is present
on unmodified main too.

One note on that measurement, since it initially looked worse than it was: my first run
showed 7 failures on the baseline and 6 with the patch. That difference was entirely my
environment — Docker's default network answers for 192.0.2.1 (RFC 5737), so the
connect-timeout tests that use it as a black hole never time out and fail
non-deterministically. After adding iptables -A OUTPUT -d 192.0.2.0/24 -j DROP both
sides settle at 572/1/2 with an empty symmetric difference.

I did not run the MSRV job locally (only 1.97.1 in the container), but that job runs
cargo check, which does not compile test code, and this change is test-only.
cargo audit and cargo machete are likewise left to CI; this change touches no
manifest.

Scope

pingora-core/src/listeners/mod.rs has the same let _ = stream.read(&mut buf) shape in
test_listen_tls, but that one only drains the request and never asserts on the
contents, so I left it alone.

[Copilot]

Pull request overview

This PR fixes a latent test flake in connectors::tests::test_connect_uds by ensuring the test reads the full 9-byte mock-server response before asserting, which matches the semantics of stream sockets (where a single write_all may be split across multiple reads).

Changes:

• Replace AsyncReadExt::read (with ignored returned length) with AsyncReadExt::read_exact in test_connect_uds to avoid short-read partial-buffer assertions.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ShanireZ]

Heads-up on the red check, so it doesn't cost a reviewer any time: the
pingora (1.97.1) failure is the cargo audit step, not this change.

It trips on RUSTSEC-2026-0258 (h2 0.3.27, "unbounded empty DATA frames"),
which was published on 2026-08-17 and is scored as a vulnerability rather than
a warning, so cargo audit exits non-zero.

Two things that show it is pre-existing rather than caused by this PR:

• The last CI run on main was 2026-08-07 (0046038), which is before the
  advisory was published. cargo audit fetches the advisory DB at run time, so
  that green run doesn't say anything about today.
• Don't compile aws-lc-rs when the ring provider is requested #966, opened before this one and touching only pingora-rustls/Cargo.toml,
  fails the same job on the same advisory ID.

This PR changes one line inside a #[cfg(feature = "any_tls")] test and touches
no manifest or lockfile, so it cannot affect that step. The other three checks
(1.85.0, nightly, semgrep-oss) pass.

Fixing it means moving off h2 0.3.x, which is well outside the scope of this
PR — I'm not touching it here, just flagging why the check is red.