Support alternative async runtimes

[rcoh]

trafficstars

Technically possible today with Tokio still used for retries, but we should be able to entirely remove Tokio as a required dependency.

[jorgecarleitao]

As long as code is written as generics over futures::*, I do not see why Tokio would be special in this context. Depending on Tokio is a big limitation if the user has a dependency over another runtime, in which case it has to ship 2 and have two thread pools performing async work.

[rcoh]

this is generally true, except for cases where a future value must be constructed synthetically. This primarily occurs when you need to perform an asynchronous sleep (required for timeouts, retries, and a few other things). Otherwise, you are correct that the code is all runtime agnostic. The smithy-async module was recently introduced as we work on abstracting this behavior.

[joshtriplett]

Is this something being worked on entirely internally, or is there somewhere that people can help with it?

[rcoh]

This can definitely get external help! The main work is actually some experimenting to find the hard Tokio dependencies. Our intentions while building were to ensure that would be possible. The note about retries in the parent issue has been resolved.

If you:

• disable the features that bring in hyper and tokio
• implement aws_smithy_async::AsyncSleep
• implement SmithyConnector (basically Tower of http::Request)

And plumb those in, I suspect we'll be very close to removing tokio from the tree. (Modulo some inevitable stumbling blocks I'm forgetting about) the result might not be ergonomic (yet) but I suspect that's where some of the work will be.

I'm also happy to provide more in depth mentorship/guidance on this as well.