ClientHello not identical when Retry is received

This originates from a Wireshark bug report: https://gitlab.com/wireshark/wireshark/-/issues/18757.

When the quiche client receives a Retry packet, it resends the ClientHello. According to the standard, this new ClientHello has to be the same as the first one, but it isn't, as the 32 random bytes are different.

> From [RFC 9000](https://www.rfc-editor.org/rfc/rfc9000.html#section-17.2.5.3):
>
> Other than updating the Destination Connection ID and Token fields, the Initial packet sent by the client is subject to the same restrictions as the first Initial packet. A client MUST use the same cryptographic handshake message it included in this packet. **A server MAY treat a packet that contains a different cryptographic handshake message as a connection error or discard it.** Note that including a Token field reduces the available space for the cryptographic handshake message, which might result in the client needing to send multiple Initial packets.
> A client MUST NOT reset the packet number for any packet number space after processing a Retry packet.

No file or test is named; start by tracing the client’s Retry-packet handling and the code that constructs the initial ClientHello, using RFC 9000 as the reference. Done means the resent ClientHello’s cryptographic handshake message, including its random bytes, matches the first one after Retry processing while packet-number behavior remains compliant.

Written by the indexing model from the issue text.