Enable async setup of an application

[mockersf]

Objective

• Async is cool. We need more async.
• Enable async initialisation of an application

Solution

• Add async variants of methods to add a plugin or a plugin group. They transform the build/ready/finish steps of the plugin init to a future, and await that future
• Inside the same app, users can mix as they want async and sync plugins, depending on what they want to do. This can be nicer for plugins that actually needs the renderer (currently the only plugin with mandatory "asyncness") to do useful work
• the #[bevy_main] macro can handle an async main function

Current state

Plugins are built when called add_plugins, then the application starts and the event loop wait for plugins to be ready then finish their setup before actually starting the application

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .run();
}

New async ✨

Plugins are built, waiting for them to be ready, then finished, and then the application can start directly

#[bevy_main]
async fn main() {
    App::new()
        .add_plugins_async(DefaultPlugins)
        .await
        .run();
}

[alice-i-cecile]

Can you say a bit more about the motivation here? Who would this be useful for, and why can't they use the existing approach?

[mockersf]

I still think an async API is cleaner, and I prefer it over the limited task executor embedded at the start of the event loop. Doing it this way is not contagious, and leave the decision to the consumer what they want to add async or sync, both can be mixed however the user want in the same app.

I also find that adding support for this doesn't require a lot of code, and the only somewhat complex part is how to handle the waker in both native and wasm (https://github.com/mockersf/bevy/blob/c50406cfb48bbb1a70300fad5935a35755b2481b/crates/bevy_app/src/app.rs#L747-L762)

It's a cleaner way to enable this kind of scenario #8553 (comment) from @JMS55

And as I may have mention, I like async things

[mockersf]

When https://blog.rust-lang.org/inside-rust/2022/11/17/async-fn-in-trait-nightly.html is stable, it will be possible to have real async plugins, and that will clean up the code nicely, while still keeping the possibility of not needing to put everything in async.
This PR is a first step for that, and show the workaround with a manual Poll implementation

[cart]

My biggest concern here is that there are now two ways to do the exact same thing and we'll likely see a mix of both in tutorials / plugins / etc. Creates questions like "which way is the right way" that have no clear answer.

[gcopeland]

Does this PR become more useful as #8624 becomes reality?

As asset loading becomes more complex and potentially longer in duration via asset processing/pipelines, doesn't support for async become more practical (especially as rust itself continues to push this) for additional user level concurrent, implementations while waiting for asset code paths to complete? If so, does async become preferred under the covers, providing a synchronous await for the current synchronous APIs?

Creates questions like "which way is the right way" that have no clear answer.

Isn't this the same answer as always? Synchronous if you want synchronous and asynchronous if you want asynchronous? Whereby continued support for this makes bevy more async friendly as it grows? Rust itself is continuing to push forward its async support. Shouldn't bevy follow? Is singular idiomatic bevy APIs the ideal for bevy vs idiomatic rust? Are they different?

[mockersf]

so... anyone ready to make Bevy full async? 😄

[alice-i-cecile]

I'm not opposed 😅 As long as there's a single way and the incantation isn't dramatically more complex, I'm fine with unblocking this work.

I would really like to get plugin dependencies and so on working properly.

[janhohenheim]

Triage: has merge conflicts