Remove HTTP client from WASM binding

[sinui0]

When the WASM binding was first implemented we baked in the hyper HTTP client to manage the connection. This was done without much consideration, and now I feel we should remove it and replace it with something closer to a socket interface.

This would put the application layer protocol burden on the user. We would have a smaller API surface to maintain (no WASM bindings for HTTP types), while the user would enjoy a greater degree of control and flexibility over the connection. For example, our WASM binding would support other app protocols such as websockets.

This would also close this issue: tlsnotary/tlsn-js#101

[pociej]

@sinui0 If I understand correctly, the client would be responsible for providing both the payload and transport layer. While we'd still need to calculate the size manually, we wouldn't need to delve into hyper's details. What about keeping hyper as the default while providing the ability to replace it? I think potential library users would find it useful to have reasonable defaults with an out-of-the-box request size calculator. Could you provide example usage with this new approach?

[sinui0]

This issue sits within a larger context regarding what our public API is and how we can ensure it is both flexible and maintainable. Maintaining a binding to an HTTP client is no small task, and is only one application layer protocol.

We'll be visiting the drawing board soon regarding this an the plugin system, we'll give folks the opportunity to comment on it once we have some materials.