We need to consolidate a lot of the async runtime behavior into a single trait that handles sleep (today, that isn't pluggable), task spawning, maybe even process spawning and file system handling. HTTP client should probably remain separate, but maybe this AsyncRuntime trait or whatever could act as a factory there.

The reason being that it's not going to be likely anyone who decides to use tokio, std-async, or other async runtime would use one for some things and another for other things. So why make callers who want to use a different, non-default async runtime (for our Azure SDK crates, which is tokio) implement (or even discover) all the traits they need to impl?

The bigger problem will be how to publish that impl. As a lib, we have to be careful with statically registering anything i.e., most likely avoid it. That has ramifications on the app that would consume us. Today, as with any other languages, we tend to pass things through IoC-style and maybe we need to keep doing that here (like we do for the HttpClient impls). Then how to "register" that impl is an app concern and they can do what is best for their app e.g., OnceLock or something.