CI: shard testing crates across multiple jobs

[fitzgen]

No description provided.

[fitzgen]

Successful default PR run in ~8 minutes now: https://github.com/bytecodealliance/wasmtime/actions/runs/9073195225

Going to do a full run in a second.

[fitzgen]

Unfortunately, it looks like cargo nextest's CI partitioning isn't exposed/supported by cargo miri.

[fitzgen]

Successful full test run in 14 minutes: https://github.com/bytecodealliance/wasmtime/actions/runs/9075621159?pr=8612

[fitzgen]

I'll also point out that this is quite a lot of sharding, more than I've ever seen done before on github actions, so while I have no reason to think things will go wrong there's always the possibility we uncover something strange in the future. Most projects I don't think approach anywhere near this concurrency. The micro_checks job is also very heavily sharded where commands that might take ~5 seconds now take ~1 minute due to the overhead of a runner, downloading rustc, downloading deps, etc. That's not going to break the bank with our concurrency limit though so I don't have any reason to not do this.

Yeah I actually wanted to group that CI job into buckets of ~10 checks each or something but I couldn't figure out an easy way to do that ¯\_(ツ)_/¯

[fitzgen]

Okay I think I figured out how to avoid having a billion check jobs

[github-actions]

Subscribe to Label Action

cc @fitzgen

This issue or pull request has been labeled: "fuzzing"

Thus the following users have been cc'd because of the following labels:

• fitzgen: fuzzing

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.