A QUIC server MAY send multiple Retry packets, so long as it does
not sent more than one per UDP datagram received:
https://datatracker.ietf.org/doc/html/rfc9000#section-17.2.5.1-3
In particular, long TLS Client Hellos that are fragmented into more
than one QUIC Initial packet and UDP datagram can result in multiple
legitimate Retry Packets.
The client MUST respond to the first Retry packet it receives and
ignore subsequent ones (which means not resetting the DCID, etc.)
(Of course, it might receive them out of order, particularly if they're
sent in quick succession.)
The handshake may, as in the sample capture, involve the client
responding to the first Retry packet with a new Initial before the
second Retry packet is received (which is ignored) and the server
accepting the new Initial and responding with its Initial after
the second Retry packet before any other packets from the client.
Also, as always, the capture might miss any of the earlier packets.
Ignore Retry packets after the client has responded to one. Also
ignore them after a server Initial. Save the original client
DCID for Retry Integrity Flags in the connection instead of clearing
it after the first Retry, because all Retry packets use the same
original DCID.
Add a test file from #20547. (This solution also works when ignoring
various of the frames, or moving the second Retry to before the
client Initial response to the Retry.)
Fix#20547
b43649759d