Hello!

It took a while but I implemented address validation token (AVT) support, wished for in #1112, for example.

With this PR, the following features are added:

• Sending of one or more AVTs per QUIC packet from the server to the client within NEW_TOKEN frames.
• Receiving, parsing and matching NEW_TOKEN frames to the path on which they were received, and from which the tokens can be taken out by the application. (The client case for token issuance)
• Setting an AVT within the Config struct to be used in the next connection attempt by a client (Client sends AVT). This AVT is only used within the next connection attempt and removed from the Config struct after usage, to not impede the common pattern of reusing the Config struct for different connection establishments.
• Setting the address to be already validated within the Config struct used by a server application where the AVT is verified by the application itself. This configuration also only applies to the next accepted connection and is reset back to allow Config struct reuse.

Furthermore, I added several testcases covering these use cases and some edge-cases.

Open questions

I can see an issue in the way I save AVTs received from the server. In my implementation, for every path I fill a VecDeque<Vec<u8>> with tokens received on the specific path. If the client does not take out the tokens regularly, they can add up, leading the application to run out of memory in the long term, especially if the server maliciously sends many large NEW_TOKEN frames. Should I change this to a ring-buffer based implementation, potentially with configurable size. imo, this does not pose any problem, as most of the time, only the newest token is interesting to us, but there are QUIC implementations out there, that send multiple NEW_TOKEN frames, which I wanted to reflect correctly.