QUIC: add support for 0-RTT packets received before the Initial

RFC9001 4.6.1: "A client that wishes to send 0-RTT packets uses the
early_data extension in the ClientHello message of a subsequent handshake;
see Section 4.2.10 of [TLS13]. It then sends application data in 0-RTT
packets."
That means the client sends before the CH (in the Initial) and then the
0-RTT (in the same UDP datagram or not)".

However, because of packet loss or out-of-order delivery, it might
happens that a 0-RTT packet is received before the Initial (the original
one or a retransmission).
For example, Google and Facebook servers save 0-RTT packets for a small
amount of time in hopes of receiving the corresponding Initial.

Update the QUIC dissector to detect 0-RTT packets and keep looking for
the Initial.

Issue found by @utoni in #1706; the trace example has been taken from that
PR.

1 files changed, 0 insertions, 0 deletions

diff --git a/tests/pcap/quic_0RTT.pcap b/tests/pcap/quic_0RTT.pcap
index 7ade88654..95e7c2b6c 100644
--- a/tests/pcap/quic_0RTT.pcap
+++ b/tests/pcap/quic_0RTT.pcap