Tracking Issue: QUIC 0.5-RTT Optimization

[marten-seemann]

#1959 proposes to prioritize making 0.5-RTT data in QUIC usable to send Identify data immediately. This would cut off 1 RTT from the QUIC handshake, bringing the time it takes to establish a libp2p QUIC connection + run Identify from 2 to 1 RTTs.

Done Criteria:

• Proposal: 1-RTT Handshakes (incl. Identify) specs#498
• enable 0.5-RTT data in quic-go: make 0.5-RTT data useable when not using 0-RTT quic-go/quic-go#3634
• introduce an EarlyListener interface that returns connections that are still handshaking, then use those for Identify
• write a blog post

[marten-seemann]

This will also require a modification to Identify.
Currently Identify works by opening a new stream, and have the peer send the identify response on that stream. This necessarily consumes an entire round trip.

What we we need to do instead is the following:

• open an Identify Push stream as soon as we start handling a new connection
• accept an Identify Push message in IdentifyWait

This is reasonable clean, the migration is ugly though. We'll have to deal with peers that don't open an Identify Push stream to us, so we'll still need to keep the old logic of doing an Identify request around. This will lead to sending the initial Identify message twice.

After a transition period, we can optimize this: On transports where we expect the server to be able to open a stream during the handshake (QUIC), we can wait for a short time (10ms? 20ms?) for the Identify Push stream, and only open the Identify stream if we don't receive one.