Default WASM32 HttpConnector

[tustvold]

Is your feature request related to a problem or challenge? Please describe what you are trying to do.

#7226 punted on defining an HttpConnector for WASM32 platforms.

Describe the solution you'd like

I would like a default HttpConnector we can use.

Describe alternatives you've considered

Additional context

[H-Plus-Time]

A couple of clarifications here, on targets:

• wasm32-unknown-unknown
  • JS-hosted: wasm-bindgen based, async, streaming work properly (though control over http protocols, sockets is not possible) in reqwest's wasm support. By far the most functional.
  • not JS-hosted: Considerably more difficult, requiring manual definitions of extern C bindings; networking and file IO in environments like this were some of the motivating examples for WASI.
• wasm32-wasi-p1
  • not JS-hosted: Network support is explicitly not part of this revision, this requires explicit host-defined, non-standard fetch equivalents. Generally this is done through vendor-specific (as in, wasmedge, wasmer, etc) crates or forks of well-known crates.
  • JS-hosted, via wasi polyfills like JCO: requires manual definitions of extern C bindings (as wasm-bindgen explicitly denies wasi targets).
• wasm32-wasi-p2
  • network support (quasi-asynchronous) is present, with the wstd crate as the likely best candidate for papering over the quasi part.
• Future, hopefully not too distant: wasm32-wasi-p3
  • this is when you'd get actual fully correct behaviour on non-JS-hosted environments.

In my view, the cases feasible to cover as part of a 1st party default HttpConnector are:

• JS-hosted wasm32-unknown-unknown. This is what's in my forthcoming PR, explicitly gated behind #[cfg(all(target_arch = "wasm32", target_os = "unknown"))].
• wasm32-wasi-p2, either host.

Anything outside of that, it should still build (and, importantly, not contain wasm-bindgen code that would trigger runtime errors), but users are on their own as far as HttpConnector is concerned.