quinn: 0-RTT is sometimes unexpectedly rejected

Both the quant maintainer and quic-tracker have recently reported 0-RTT sometimes being rejected when it shouldn’t be. Manual local testing with quant and the interop server has so far failed to reproduce this. The server logs “dropping unexpected 0-RTT packet” instead of “0-RTT enabled”, indicating that the call to rustls’ get_0rtt_keys() failed, so something’s happening at that layer: either SessionCommon::get_suite() is returning None, the PSK isn’t being successfully decoded in CompleteClientHelloHandling::handle_client_hello, or ExtensionProcessing::process_common is unsetting the quic.early_secret due to some condition that requires early data to be rejected.

If we can manage to reproduce this locally, it should be straightforward to identify which of these cases is responsible by stepping through with a debugger and/or adding diagnostic prints inside rustls. The responsible case can then be sanity-checked against the TLS 1.3 spec.