Webtransport support quic/http 3

[martenrichter]

This PR is done to discuss early changes required for webtransport.
It is not intended for merging, as it uses an experimental PR of nghttp3, so rebases are required in the end.
Main objective is to discuss also the API on the way.

Currently, I use during the development the higher level functions of my node.js package, which has a special branch for the webtransport implementation:
https://github.com/fails-components/webtransport/tree/nodenativequic (branch for the implementation)
Relevant files are in:
https://github.com/fails-components/webtransport/tree/nodenativequic/main/lib/http3native
I have only the bare minimum of functions in node.js, as I believe that will give developers more control. So W3C interface is my package for now. (but also here will be feedback valuable)

Currently client, session and stream are partially implemented.
I am going step by step through all test I have.
I pass test 1 of:
https://github.com/fails-components/webtransport/blob/nodenativequic/main/old_test/testsuite.js
(old test, usually first to check when implementing;).
Test 2 fails. (Probably not a WT specific issue #63784).

The plan is :

• Make all old test run
• Go to the newer tests and fix them
• Implement server side
• Make all old test run (server side)
• Go to the newer tests and fix them (server side)
• Convert tests to node.js tests

But it will take time.

@pimterry @jasnell : Please invite other people who should take part in the discussion.

[nodejs-github-bot]

Review requested:

• @nodejs/quic
• @nodejs/security-wg

[pimterry]

Thanks @martenrichter, super interesting! This is great and I'd definitely be keen to include WebTransport as soon as we can, though it'll probably have to wait until nghttp3 merge the draft this depends on, which in turn looks like it's currently waiting on the final RFC.

This approach in rough concept looks like it'll fit neatly with the HTTP/3 API changes & internals split I'm going to propose shortly (aiming for a PR on Monday I think) so there shouldn't be a big practical issue to implement WebTransport with that. In practice for this code specifically I should warn you there's going to be massive conflicts line-by-line since I'm moving lots of things around, but it's largely just relocation rather than more substantial changes.

The only relevant that might change in approach is the ticket data and application options part, since I'm adding a new API to better split transport params from app ticket data, and pull application options entirely out from QUIC into the specific application implementation. It'll make sense shortly I hope 😄 watch this space.