Case study on the initialization of the WebTransport

[MOZGIII]

WebTransport is supposed to be a single unified protocol with just one API, and it pretty much is that when it comes to the actual runtime.

The setup phase, however, is suuper diverse - like with native rust you'd want to have control over all low-level aspects - like the ability to bind the socket to a specific port, specify custom TLS validation scheme and etc... With the Web and WASM however you are limited to a set of very indirect settings - like some light TLS trust mode tweaking (cert hashes) - and that is already awesome btw, yet still so high-level and limiting - and things like high water mark for controlling the congestion (while in your native code you can control it directly and explicitly).

So. We'd still want to avoid having the separate APIs for each of the driver's setup. Driver is, in this terminology, a crate that implements the xwt-core API, so xwt-web-sys, xwt-wtransport and etc. Note, btw, that we don't call them xwt-web and xwt-native - cause there maybe more than once native implementation (and likewise there can be more than one web implementation - but who needs that :D).

Anyhow, people are annoyed by the need to do some low-level setup and compile-time target-conditioned branching in their setup code. This is understandable and is a problem, so let's try so solve this.

The current design is crafted in such a way that immediately pushes the developer to bring in the dependencies to do the setup explicitly by constructing driver implementation details before wrapping them into the actual driver - and this is very much intentional - to force full flexibility (vs provide a restricted "lowest common denominator" solution).

Can we improve on this somehow? Figure out a single unified API for the setup too? Or leave it as is? Let's talk.