Add support for QUIC stateless reset

[csujedihy]

This PR introduces RFC 9000 stateless reset support to quiche and tokio-quiche. Before this change, quiche already has an incomplete implementation of stateless reset where the stateless reset on-wire token is directly exposed in control interfaces (quiche::Config::set_stateless_reset_token and tokio-quiche::QuicSettings::stateless_reset_token). Basically, with raw quiche, the app would have to implement stateless reset on their own, like deriving a token from a static key, constructing a stateless reset packet from scratch etc. With tokio-quiche, its completely broken because it sends the same token for all incoming connections and it can only generate randomized token for NEW_CONNECTION_ID frames.

This PR:

1. Introduces new control interfaces (quiche::Config::set_stateless_reset_key and QuicSettings::stateless_reset_key) where the app can supply the static key for token generation.
2. Adds helpers for building the stateless reset packets for raw quiche applications.
3. Adds support in tokio-quiche to send stateless reset token (derived from the static key) in TPs and issue new CIDs with reset token derived from the static key. Basically, the app just needs to set the key and everything works.
4. Adds client support for handling stateless reset.
5. Adds reset issuance rate-limiting, which only allows 1 reset outstanding per-2-tuple (IP:port).

Things to note:

1. The old tokio-quiche::QuicSettings::stateless_reset_token isn't removed because we want to take this change in before the upstream change is merged and we don't wanna break internal cloudflare ZT stack.
2. No server side reset receipt logic for simplicity (not practical in reality for a client to send resets).

[gregor-cf]

This is great. I just had a couple of smaller nits.

[gregor-cf]

When sending stateless resets, I'm wondering if we want to do more aggressive limiting than the current "in-flight" logic. E.g., if a connection with a lot of packets in flight arrives at a new server and it needs to send state-less resets, we could potentially send one stateless reset per incoming packet. Not the end of the world and TCP would do the same IIRC, but we could consider limiting to one reset per 2-tuple every couple 100ms to every second. But it's not clear that the complexity would be worth it.

[csujedihy]

When sending stateless resets, I'm wondering if we want to do more aggressive limiting than the current "in-flight" logic. E.g., if a connection with a lot of packets in flight arrives at a new server and it needs to send state-less resets, we could potentially send one stateless reset per incoming packet. Not the end of the world and TCP would do the same IIRC, but we could consider limiting to one reset per 2-tuple every couple 100ms to every second. But it's not clear that the complexity would be worth it.

msquic exactly does this and I originally wanted to do the same but simplified it. I don't think it's super complicated. We'd need a hashmap instead of a hashset to store the last_sent timestamp and a heap to evict expired entries opportunistically. I can add it.