relay/dcutr/quic: Alternate host sending garbage UDP packet

Today during direct connection upgrade on QUIC, A sends a client hello, B sends random bytes. The client hello makes it through B's firewall and/or NAT through the hole punched by the random bytes sent by B. B's consecutive server hello makes it through A's firewall and/or NAT through the hole punched by A's client hello.

• For a QUIC address:
  • Upon receiving the Sync, A immediately dials the address to B.
  • Upon expiry of the timer, B starts to send UDP packets filled with
    random bytes to A's address. Packets should be sent repeatedly in
    random intervals between 10 and 200 ms.
  • This will result in a QUIC connection where A is the client and B is
    the server.

https://github.com/libp2p/specs/blob/master/relay/DCUtR.md#the-protocol

Now assume that B is behind a symmetric NAT but A is not. A's client hello will not make it through B's NAT, given that it (most likely) does not have the same destination port as the translated source port of B's random bytes.

If we would alternate the roles on retries in DCUtR, e.g. have B be the one to send random bytes in round 1 and A be the one to send random bytes in round 2, the above scenario would succeed on the second try, given that B is not behind a symmetric NAT.

Note that we could as well have both A and B send client hellos in the first round. The downside is, that contrary with TCP and simultaneous open, we might end up with two QUIC connections. One from A to B and one from B to A.

//CC @elenaf9 and @dennis-tra as discussed today.

Start with the DCUtR protocol section linked in the issue and review the described QUIC address exchange, retry timing, and alternate-role proposal. Determine the intended retry behavior and document the agreed protocol change, including how completion is verified without creating duplicate connections.