quinn: expose accepted_0rtt() on Connection

[HuginSecurity]

Summary

The high-level quinn::Connection wrapper omits accepted_0rtt() even though quinn_proto::Connection already exposes it publicly. Server-side consumers that accept 0-RTT early data need this signal to safely gate replay-sensitive operations (e.g. non-idempotent HTTP methods on an HTTP/3 MITM listener) without falling back to time-window heuristics.

This adds a one-line delegation. No behavioral change to other code paths.

Motivation

Building an HTTP/3 MITM interception proxy (Hugin), I needed to decide per-request whether to reject non-idempotent methods (POST/PUT/PATCH/DELETE) that arrived as 0-RTT early data — replayable and therefore unsafe for anything with side effects. The only public signal available was a time-since-handshake heuristic ("if the stream arrived within N ms of handshake start, assume it's 0-RTT"), which is imprecise under network jitter and adversarial timing.

The exact signal already exists in quinn_proto::Connection::accepted_0rtt(). Exposing it on the high-level Connection closes the gap with no new API surface on the proto side.

Test plan

• Local build + test of a downstream project using the accessor
• Any upstream tests reviewers would like me to add (happy to extend)

Notes

Targeted at main off tag quinn-0.11.9. The change is a single public method; semver-compatible as a minor-version addition.

[Ralith]

The given motivation is confused. 0-RTT application data is only processed prior to the handshake by explicit application action: if you don't call Connecting::into_0rtt, then there is no way for you to receive any application data until the handshake has succeeded, at which point there is no replay hazard.

If your TLS configuration allows 0-RTT, then it is always unconditionally "accepted" (in the formal sense exposed by this accessor) regardless of whether you choose to process it before handshake completion, and regardless of whether any particular stream I/O occurred before or after the handshake. The peer which typically cares about this is the client, which needs to know if 0-RTT data it sent was discarded. That information is already exposed in the ZeroRttAccepted future.

I think what you actually want to know is whether an individual stream read completed prior to the handshake. That information is already available in the completion timing of the ZeroRttAccepted future.

[flub]

I think you are after https://docs.rs/quinn/latest/quinn/struct.RecvStream.html#method.is_0rtt if you need to decide whether to accept non-idempotent operations.