Especially the sentPacketHistory linked list shows up in allocation
profiles, since a new list element is allocated for every single packet
we send.
Using a pool for the receiving path, as well as for the frame sorter, is
less critical, since we're tracking ranges there instead of individual
packets / frames, but it doesn't hurt either.
The other occurrences where we use a linked list (connection ID tracking
and the token store) are used so rarely (a few times over the lifetime
of the connection) that using a pool doesn't make any sense there.
Duplicate detection uses the same data structure that is used to track
received packets to generate ACK frames. That means that after an old
ACK range has been pruned, a severly delayed packet might be incorrectly
detected as a duplicate.
As we wouldn't have acknowledged receipt of this packet, this situation
would have resulted in a retransmission by the peer anyway, so dropping
the packet won't cause a big regression.
The value was not updated correctly when receiving reordered packets.
Since it's trivial to determine it from the list of received packets,
the easiest fix is to remove it.
