Allow wasm to compile

[rylev]

Fixes #906

This cleans up our wasm support a bit and paves the way for actual wasm support to be added in the near future.

User experience

Users can now compiler for wasm32 targets as long as the reqwest features are not turned on (since reqwest does not have wasm support).

If the user compiles for wasm32 targets with the reqwest features enabled (as they are by default), they see the following error.

$ cargo c --target=wasm32-unknown-unknown -p azure_data_cosmos 

Checking azure_core v0.3.0 (/home/rylevick/code/azure-sdk/azure-sdk-for-rust/sdk/core)
error: The `enable_request` and `enable_reqwest_rustls` features are not allowed for `wasm32` targets`
  --> sdk/core/src/http_client/mod.rs:11:1
   |
11 | compile_error!("The `enable_request` and `enable_reqwest_rustls` features are not allowed for `wasm32` targets");
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: could not compile `azure_core` due to previous error

The noop client

We currently don't support any way for users to make requests when compiling for the wasm32 target. In the future, we will provide an easy way for users to supply there own transport policies. Users who compile for wasm in the browser, can provide a transport policy that uses the browser APIs, while users compiling for wasi, can use a transport policy that uses wasi based APIs.

Since there is (IMO) no obvious default, we have a NoopClient that simply panics and prints out the outgoing request. Most users who will be using the reqwest feature, will never run into this.

Some challenges

This solution isn't 100% elegant, but is IMO an improvement over the status quo. There are some downsides though:

• We do enforce Send futures for wasm targets. This causes us to have to propogate this out since by default BoxFuture and the Futures created by the async_trait macro are all constrained to be Send. So, we still have a lot of cfg markers for wasm, but there in much more predictable places and we don't have to add a bunch of allow(unused) directives everywhere.

[rylev]

@ctaggart @bmc-msft this should be ready to merge!

[bmc-msft]

In all of our uses, azure_core is set to default-features=false. Perhaps we should not set default features for azure_core, and have it's dependencies do that?

❯ rg -I ^azure_core -g '**/Cargo.toml' | sort -u
azure_core = { path = "../../../sdk/core", version = "0.3", default-features = false }
azure_core = { path = "../core", version = "0.3", default-features = false }
azure_core = { path = "../core", version = "0.3", default-features = false}
azure_core = { path = "../core", version = "0.3", default-features=false }
azure_core = { path = "../core", version = "0.3", default_features = false }
❯

[radu-matei]

For WASI support, I've been using a modified version of this SDK that works with https://github.com/deislabs/wasi-experimental-http and Wasmtime — main...radu-matei:azure-sdk-for-rust:enable-wasi-experimental-http

[rylev]

@radu-matei awesome! I hope to have a change soon that allows for easily swapping out the transport policy. Once that's done, it should hopefully be easy to have a wasi backed transport policy that can be swapped in without the need for modifying any of the code.