feat: Add anyspawn crate with generic Spawner trait for spawn tasks for different async runtimes

[schgoo]

No description provided.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.0%. Comparing base (59cd599) to head (bea04e0).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #193   +/-   ##
=======================================
  Coverage   100.0%   100.0%           
=======================================
  Files         135      138    +3     
  Lines        8199     8230   +31     
=======================================
+ Hits         8199     8230   +31     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[martintmk]

Have you thought about applying this guide to spawner?

https://microsoft.github.io/rust-guidelines/guidelines/libs/ux/index.html?highlight=trait#M-DI-HIERARCHY

The idea is that Spawner would be just a normal struct that would expose multiple constructors to create it.

For example:

Tokio:

let spawner = Spawner::new_tokio();

Custom Runtime:

let spawner = Spawner::new_custom(move |future| runtime_handle.spawn(future));

The Spawner would just accept futures of type Future<Output = ()>, but it could also expose additional methods on public APIs that would work with result-returning types. This could be archived by using some oneshot-based async channels.

The downside of this approach is that we would enforce Send and Sync bounds, but this is aligned with https://microsoft.github.io/rust-guidelines/guidelines/libs/interop/index.html?highlight=Send#M-TYPES-SEND.

[schgoo]

Have you thought about applying this guide to spawner?

https://microsoft.github.io/rust-guidelines/guidelines/libs/ux/index.html?highlight=trait#M-DI-HIERARCHY

I can see the value here. I guess the tradeoff would be some additional heap allocations and indirection internally, since the new_custom(...) closure will have to accept a boxed future. Once Oxidizer RT moves here we can add a direct enum variant for it to avoid that additional cost. In fact, we can probably remove this abstraction altogether at that point.

[martintmk]

I can see the value here. I guess the tradeoff would be some additional heap allocations and indirection internally, since the new_custom(...) closure will have to accept a boxed future. Once Oxidizer RT moves here we can add a direct enum variant for it to avoid that additional cost. In fact, we can probably remove this abstraction altogether at that point.

I see the value of this type even when oxidizer rt is public. Sometimes, the library only needs to care about how to spawn tasks and using this type can simplify those scenarios.

[martintmk]

few nits, otherwise looks good