bug: not reassembling CRYPTO frames over multiple Initial Packets

[gaukas]

It is possible for a QUIC client to send it is initial frames over multiple initial packets in the beginning of the (UDP) communication.

For example, Google Chrome 122 with Kyber768-based post-quantum Key Share enabled will need to send an oversized TLS ClientHello which is over 1700 bytes, exceeding the limit of ~1200 bytes per initial packet itself. Chrome instead sends the first Initial Packet (PKN: 1) with only a CRYPTO frame with a fixed size (~1200) and offset 0, followed by another Initial Packet containing the rest of TLS ClientHello in multiple smaller CRYPTO frames along with other frames including PING/PADDING.