Always Send Futures

[rylev]

This PR removes the distinction between wasm32 targets and other targets when it comes to whether futures are Send or not. This makes it so that futures must always be Send. This greatly simplifies the code.

In order for this to work though, we need to be able to move away from requiring Reqwest. This requires two further changes:

• implement oauth2 HTTP client #996
• Migrate keyvault to pipeline #962

Thoughts?

[rylev]

@radu-matei @Mossaka as people working in the WASM space, what do you think of this change? This would require all implementations to produce Send futures. This means that if you're making network calls (for example, in a wasi environment), your HTTP implementation must be fine being sent to another thread.

This also means that this crate is not really useable for browser based WebAssembly (since the http implementation is !Send) and probably even for node.js. There are work arounds like send_wrapper which makes sending a !Send value possible (and using it from another thread a runtime panic), but we probably don't want to require users to do this.

[ctaggart]

This also means that this crate is not really useable for browser based WebAssembly

Our crates need to be usable in the browser via WebAssembly.

[rylev]

@ctaggart can you talk more through the use case for browser WASM? Wouldn't there be issues with cors?

[rylev]

Discussed this with folks, and we agree we want to support running this SDK in the browser.