Support async_std

[bahildebrand]

#323 exposed a need to support multiple runtimes. This will most likely need be exposed by a new feature flag that would choose between tokio and async_std.

Additionally, there have been calls to support a non-async version(#317). We may be able to kill two birds with one stone here, but the primary focus will be adding support to async_std.

[Fishrock123]

For reference, here is the Tide Listener for lambda that I implemented: https://github.com/Fishrock123/tide-lambda-listener

Ideally this would run on top of something lambda_http, since you can feed http_types::Requests directly into Tide. (Via tide::Server::respond().)

This uses Surf as the http client, using the "h1-client-rustls" feature to have the http-client implementation be backed by async-h1 rather than the still-present-default of libcurl via Isahc (this is planned to change to async-h1 client by default in Surf 3.0). The "unstable-config" feature of http-client is used to gain control over timeouts (as I am the maintainer of http-client, there is a level of stability guarantee here, and it should become stable soon enough).

One note of differences here is that the http_types stack does not allow you to construct Request structs with partial url fragments, instead they must all be complete urls.

Presently it uses the conversions back-and-forth between hyperium http via https://github.com/http-rs/http-types/blob/main/src/hyperium_http.rs to use the http code from this repo (in a patched, exposed form).

async-native-tls and isahc are both avoided to prevent the need for cross-compilation to musl.

[Fishrock123]

It would probably also be handy (once the time comes) on this end of things to separate source code folders here between hyperium/tokio and http-rs/async-std.

[calavera]

hey folks, we've decided not to do this for the time being. If anything changes, I'll let you know.

[Dgame]

@calavera May I ask how difficult it would be to support this?

[calavera]

No idea. I'm guessing it's technically possible. Libraries like the AWS SDK only support Tokio too, so the large majority of users will end up using our current async runtime anyways. That's why it's not a goal for this project to support multiple async runtimes at the moment.