CI: Use Rust cache

[oeb25]

This adds Swatinem/rust-cache@v2 to all CI jobs, with the intention of speeding them up. Hopefully we can compare some runs to get empirical data of the improvements it gives.

Pre-review checklist

• I have split my patch into logically separate commits.
• All commit messages clearly explain what they change and why.
• I added relevant tests for new features and bug fixes.
• All commits compile, pass static checks and pass test.
• PR description sums up the changes and reasons why they should be introduced.
• I have provided docstrings for the public items that I want to introduce.
• I have adjusted the documentation in ./docs/source/.
• I added appropriate Fixes: annotations to PR description.

[Lorak-mmk]

Thanks for the contribution!

Do you know why the CI failed? Is it just a one-time fluke or some problem with PR / cache action / cargo?

Regarding the changes:

• First commit looks fine
• I don't understand the purpose of second commit. Could you describe in the body of commit message why is it beneficial to add the usage of dtolnay/rust-toolchain / taiki-e/install-action? Also, could you rewrite the message to make it's title shorter? Right now it's wrapped around by GitHub.

Also, could you rebase on latest main?

After you push the changes, the CI will run again so we'll know if the failure was just a one time error or some real problem.

[Lorak-mmk]

What's wrong with the toolchain that is already on the runners?

[Lorak-mmk]

What's the advantage of this?

[Lorak-mmk]

Regarding timings: comparing durations here vs the last CI run from other PR:

• Authenticate: 2:12 vs 2:34
• Book: 2:44 vs 4:20
• Cassandra tests: 7:51 vs 8:50
• Rust: 6:53 vs 10:33
• SSL: 1:24 vs 2:37
• min_rust: 0:39 vs 4:27
• cargo_docs: 0:54 vs 0:30
• Serverless: FAIL vs 5:25

It seems there are visible gains, so it would be nice to merge this PR.
I'd like to see some more timings, after rebasing on main, to make sure the differences are consistent.

[wprzytula]

@oeb25 What's the status of this?