The `dtolnay/rust-toolchain` action accepts a lot of options, including things like "stable 8 weeks
ago". Instead of trying to have this action validate the input, we'll leave it to
`dtolnay/rust-toolchain`.
This also adds tests using non-stable toolchains.
Until https://github.com/cross-rs/cross/issues/1628 is resolved, running cross on Linux ARM also
requires the user to provide a custom Docker image, so this is only sort of usable.
If the target is ARM and the host is ARM, this should work with just `cargo`. I'm not sure if this
works for all ARM host/target combos, or if the CPU architecture must be an exact match.
But it doesn't really matter too much, since at least for now there's no ARM builds for
`cross` (https://github.com/cross-rs/cross/issues/1612). So even if cross-compilation doesn't work
natively, we couldn't use `cross` in this case either.
I also rewrote the `set-cross-compile.sh` in Python. By "I", I mean I had Claude do it and then I
tweaked it.
It seems like restoring the cache for subcrate deletes sometimes removes the compiled binaries for
the parent crate. I'm not sure what's going on here, as it doesn't happen every time.
If we're running cargo, we need to add the runner name to the cache. Otherwise things that link
against system packages, like openssl, can break when we use the same cache across different
versions of the runner OS. For example, when going from Ubuntu 20.04 to 22.04, we move from OpenSSL
1.1.x to 3.x.
For test commands, there can be arguments passed to the test binary like `-- --ignored` or `--
--test-threads=1`. For these cases to work properly, the `args` parameter needs to be added to the
end of the 'test' command.