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.
There are two checks that need to be performed:
1. the crypto stream must not have any more data queued for reading
2. when receiving CRYPTO frames for that crypto stream afterwards, they
must not exceed the highest offset received on that stream
