dcutr/quic: prepare own router with low TTL packet first

Thanks to a friendly exchange at FOSDEM '23, we were pointed to this p2p crate. This crate specifically implements NAT hole punching techniques and I believe we could draw some inspiration from them.

Especially the TTL approach sounds interesting. Their documentation describes a scenario where it would be beneficial here: https://docs.rs/p2p/0.5.2/p2p/#endpoint-address--port-dependent-filtering-port-restricted-cone

The idea is to prepare one's own router for the remote packets by sending low TTL packets to the remote. The problem we solve here is that if our UDP packets were to reach the NAT of the remote peer before the remote peer sent packets to us, an unfriendly NAT/router could denylist us for some time.

My proposal for a protocol optimization would be:

1. When the first CONNECT message reaches the remote peer, it starts sending UDP packets with a TTL of 3 to the addresses contained in the CONNECT message
2. When the second CONNECT message reaches the local peer, it does the same until the sync timer has fired.

Why 3? The documentation of the p2p crate says: "In practice it's usually the 1st couple (or 3) routers that do NAT while others are non-NAT."

Something that would speak against this protocol optimization is the fact that hole punching is not really sensitive to timings, it seems. At least that's what our measurement campaign suggests. I'm opening this issue to also brainstorm if we could quantify the potential of this change from the data that we have gathered.

cc @mxinden

Start with the linked p2p crate documentation and the referenced NAT hole-punching measurement campaign. Then locate the CONNECT handling and sync timer in the implementation to assess the proposed TTL-3 packets. Done would require a decision, supported by measurements, on whether this protocol optimization is worthwhile.