CI: Linux test often takes >1h

[RalfJung]

Recently it seems like the test job running on Linux has become quite a bit slower, often taken close to 1h30min and often being the slowest job to complete.

I'm not quite sure when this started; unfortunately it seems like GHA has no good way to track CI time over time. If I go back about a month, I usually see CI times of around 50min for the Linux job, a bit more than 30min for the Windows job, and a bit less than 30min for the macOS job. Now the Linux job is 40min slower and the other two are about 20min slower.

Did GHA get slower or did our CI get slower?
Also, maybe we should split up the Linux job into multiple jobs so that they can run in parallel. However that will increase overall CI resource usage since Miri is then built more often.

[RalfJung]

Looking just at the nightly CI, this one was still good:
https://github.com/rust-lang/miri/actions/runs/7839746950
And this one is slow:
https://github.com/rust-lang/miri/actions/runs/7867399849

The ones in between did not pass. Nothing significant changed in Miri in that time, so it can probably only be some rustc change? Looking at the rustup PRs, this is the first slow one:
https://github.com/rust-lang/miri/actions/runs/7852837474
(for comparison, this is the one before: https://github.com/rust-lang/miri/actions/runs/7825262517)
That's this PR:
#3293
Corresponding to this rustc range:
rust-lang/rust@384b02c...b5c46dc
This includes @saethlin's rust-lang/rust#120594, so I wonder if that is to blame. We specifically run CI with debug assertions + optimizations, so it fits the profile.

[oli-obk]

However that will increase overall CI resource usage since Miri is then built more often.

There are shenanigans we can do where CI builds miri, then sends information to n CI jobs that then run in parallel

[RalfJung]

With rust-lang/rust#121114, CI times are back to normal. :)