Consolidate together Bevy's TaskPools

[james7132]

Objective

Fixes #1907. Spiritual successor to #4740, #12090, and #18163. Third time's the charm!

Bevy currently creates a 50%/25%/25% split between the Compute, AsyncCompute, and IO task pools, meaning that any given operation can only be scheduled onto that subset of threads. This is suboptimal in the cases where apps are not using any IO or Async Compute, or vice versa, where available parallelism would be under utilized due to the split not reflecting the actual use case. This PR aims to fix that under utilization.

Solution

This is based on #20649 and #20331. Unlike #12090 and #18163, this does not introduce any blocking thread pool (albiet those do still exist since we use async-fs / unblock in bevy_assets), and, in fact, does not make a major departure from the current status quo:

• Do away with the IO and Async task pools and allocate all of the threads to the now consolidated TaskPool.
• Provide a set of task priorities:
  • RunNow - When woken, these tasks are scheduled to immediately run after the currently running task yields.
  • Compute - Replaces the ComputeTaskPool's purpose.
  • AsyncIO - New. Dedicated to IO tasks that yield regularly with fairly low amounts of compute when woken. Ideal for network IO.
  • BlockingCompute - Replaces the AsyncTaskPool's purpose.
  • BlockingIO - Replaces the IoTaskPool's purpose.
• Priority groups are limited by semaphores inside the executor. New or freshly woken tasks in groups that are at the limit are pushed back onto the queue to run later. These limits, by default, apply to all groups with priorities below Compute. This allows any task to freely use any thread in the task pool when scheduled, and prevents the lower priority groups from starving out higher priority tasks.

This isn't strictly reliant on #20649, but it does make it easier to implement. The diff with that PR can be seen here.
This PR will remain in draft until #20649 or some equivalent is merged.

Testing

Right now, just bsaic example testing.

Future Work

• Find ways to prioritize scheduling latency sensitive tasks onto higher performance cores (e.g. Intel's P-Cores) and lower priority background tasks onto more power efficient CPU cores (e.g. Intel's E-Cores).

Co-Authored By: Mike Hsu mike.hsu@gmail.com

[github-actions]

The generated examples/README.md is out of sync with the example metadata in Cargo.toml or the example readme template. Please run cargo run -p build-templated-pages -- update examples to update it, and commit the file change.