Create API for http/3 extensions like WebTransport

Current Solution for WebTransport

The Solution for WebTransport wraps the server::Connection in a Mutex to allow listening to incoming streams (uni and bidi) and also to open new steams.
https://github.com/hyperium/h3/blob/9b028247dcefa6f6f323908135b98a958f1bf30d/h3-webtransport/src/server.rs#L44-L56

Additional resources like new Settings, Streams, Frames or Protocols for the :protocol pseudo header are defined and parsed within h3 itself and not h3-webtransport.

webtransport frames for example are atm handled in the h3 core.
https://github.com/hyperium/h3/blob/9b028247dcefa6f6f323908135b98a958f1bf30d/h3/src/proto/frame.rs#L86-L94

So new extensions require changes in h3 itself, which can become very complicated.
A few references: #236 #273

Loose thoughts about what features such an extension API might require

An Extension API IMO should have the following features:

• Ability to send custom Settings, Streams, Frames and Protocols for the :protocol pseudo header
• Ability to react to custom Settings, Streams, Frames and Protocols for the :protocol pseudo header
• Acces to the Quic types which implement h3-quic traits and potentially acces to some lower level structs like FrameStream or BufRecvStream

Some loose ideas

I have a few ideas on how this could be achieved, but nothing completely thought through.

Give another generic Parameter to the h3 connection
An additional generic Parameter could be added to ConnectionInner (or maybe client::Connection / server::Connection directly?).
This generic Parameter could either be:

• A custom Trait defined in h3 where each each "event" is a method
• Fn(Args) -> () + Clone. With Args as an Enum with a variant for each "event"

When specific events occur while polling the the connection, the extension could react for example to the event when a unknown stream or frame is received.

When using traits this could be combined with custom types for custom Settings, Streams, Frames, etc.

Access to low level types in order to start streams and send.

Open Question

• Where should the CONNECT Request be handled? h3? extension? user?

Whats next

• please share your thoughts on this
• figure out more details (maybe while implementing a prototype)

Start by reading h3-webtransport/src/server.rs around the Connection wrapper and h3/src/proto/frame.rs around WebTransport frame handling. Review the related discussions in #236 and #273, then prototype the extension boundary described here. Done means an agreed design covering custom settings, streams, frames, protocol handling, and CONNECT ownership.