feat: WebTransport on top QUIC transport

[dgarus]

related to #2993

@thomaseizinger
Hi! There were so many changes in the master branch, so it was easier for me to create a new PR from scratch. I tried to consider all your previous comments and our discussions.

Here are the main points:

Instead of rolling certificates, I'd suggest (something like) the following:

Give our users a simple API to generate and parse certificates
Allow the user to pass in a list of certificates in the QUIC config, explicitly for WebTransport
For the QUIC functionality, we can generate one similarly to how we do it currently
When the user calls listen_on for webtransport, we validate the certificates have a valid date range (the webtransport spec requires +/- 14 days I think)
Whilst not super convenient, this allows users to externally manage certificates until we can generate them deterministically. 
What is important is that we give users some way of restarting a libp2p-node and retain the certificate. 
WebTransport is of no use if the certificate hashes change constantly.

I would like to avoid interacting with the file system as much as possible. My suggestion would be:

- libp2p::webtransport::Transport::new takes a list of certificates (of type libp2p::webtransport::Certificate)
- libp2p::webtransport::Certificate::generate allows users generate a new certificate with certain parameters (validity date etc)
- libp2p::webtransport::Certificate::{parse,to_bytes} allow users to serialize and deserialize certificates

For simplicity, I made a single cert.

Let's consider the following scenario:

User calls listen_on for /quic-v1
User calls listen_on for /webtransport using the same port
Another peer attempts to connect using the /webtransport address
The incoming connection will be picked up by one of the two listeners. 
Until we inspect the Connecting struct, we don't actually know whether it is a QUIC or a WebTransport connection.

So I think what we need to do is:

At most have 1 Listener for a given socket address
The listener needs to be one of 3 modes:
- Only QUIC
- Only WT
- Both
When we receive a listen_on for a socket with an existing listener, we need to update its mode
For incoming connections, we need to inspect it whether it is a QUIC or 
WT connection and check whether the listener supports whatever is incoming. If yes, upgrade it accordingly.

[dgarus]

@jxs Hello!
Please review this PR as well.
This is a draft, but before cleaning it would be great to know what you think.
Thanks!

[thomaseizinger]

Thank you @dgarus ! I hope to give this a review soon.

[dgarus]

@thomaseizinger
Thank you so much for your efforts!
Currently, I’m stuck with an integration test writing. The problem is what can i use as a webtransport client?
I'm looking at transports/webtransport-websys/src/transport.rs. What do you think this is a good idea using webtransport-websys to test webtransport transport?

[thomaseizinger]

@thomaseizinger Thank you so much for your efforts! Currently, I’m stuck with an integration test writing. The problem is what can i use as a webtransport client? I'm looking at transports/webtransport-websys/src/transport.rs. What do you think this is a good idea using webtransport-websys to test webtransport transport?

You should get some basic coverage by adding webtransport here:

rust-libp2p/interop-tests/native-ping-version.json

Line 4 in 3837e33

"transports": [