client: classify post-deadline transport failures as deadline_exceeded

[iainmcgin]

Fixes #210.

The race

A server enforcing the same deadline aborts the RPC independently, so its RST_STREAM can arrive before the client's own timer fires. The in-flight body read then fails first, and the call reported internal — attributing to this client what was really a timeout the caller asked for.

Which of the two wins is down to timer coarseness and scheduler delay, so the same call could report either code run to run. That is what makes the gRPC client conformance Timeouts cases flaky on a loaded host, on main as much as on any branch.

The fix

The missing-grpc-status path already resolved this by deadline rather than by arrival order. This applies the same rule at the three body-read sites, through one classifier:

fn classify_body_read_error(context: &str, error: &dyn Display, deadline: Option<Instant>) -> ConnectError {
    if deadline_elapsed(deadline) {
        ConnectError::deadline_exceeded(format!("{context} after the deadline elapsed: {error}"))
    } else {
        ConnectError::internal(format!("{context}: {error}"))
    }
}

The four places that ask "is the deadline past" now share one deadline_elapsed predicate rather than three hand-inlined copies, so they cannot drift apart.

collect_body_bounded and the two Connect parse functions had no deadline to consult, so it is threaded in. It is used only to classify — with_deadline still does the enforcing, and the doc on collect_body_bounded says so to head off the obvious misreading.

The transport cause is preserved in the upgraded error. A genuine transport fault that merely happened after the deadline should stay diagnosable, and the code is what callers branch on, not the message.

Connect gets this too, not just gRPC. connect-timeout-ms produces the identical race and collect_body_bounded is shared, so scoping the fix to gRPC would have been arbitrary.

Evidence

The gRPC client conformance suite, same host, same load:

	runs	result
before	3	1, 3 and 5 failures — all Timeouts/..., all internal vs expected deadline_exceeded
after	5	1454 passed, 0 failed every run

No movement elsewhere: Connect client 2580/0, gRPC-Web client 2838/0, server 3600/0.

Three unit tests pin the branch directly — past the deadline gives deadline_exceeded and keeps the cause, before it stays internal, and no deadline stays internal without picking up timeout wording.

Deliberately not in scope

Two Connect sites classify a clean body EOF without a terminus as internal without consulting the deadline, where the gRPC equivalent (classify_grpc_end) does upgrade. Those fire on graceful EOF rather than a transport error, so they are a different failure mode — a close without a terminus is more likely a protocol violation than a race. Flagging it because the asymmetry should be a decision rather than an accident; happy to file a follow-up.

One note recorded in the code for future test authors: deadline_elapsed reads the real clock while with_deadline runs on tokio's, so under #[tokio::test(start_paused = true)] virtual time advances and this does not. A paused-time test that delivers a body error and expects the timeout classification will not get it.

Testing

Clippy on the pinned 1.95 toolchain, cargo test -p connectrpc --no-default-features (423), 56 test suites, lint, fmt, and the four conformance suites above.