Explore using cargo-hakari to avoid duplicate builds between miri test and miri run

[RalfJung]

./miri test and ./miri run currently each build their own copy of the Miri binary. The reasons for that are described here. The tool https://crates.io/crates/cargo-hakari is intended to help with cases like that when they arise in a workspace; maybe they also help with the situation of multiple crates within a single package.

[RalfJung]

One challenge might be that the crate can't be in a workspace -- this entire repository is embedded in the rustc repo as a subtree, and rustc makes Miri a workspace member, so Miri's Cargo.toml can't itself be declared a workspace root.

@sunshowers is that a problem for hakari, or does it also work for non-workspace crates?

[sunshowers]

Hmmm, interesting. I've never tried it on single-crate projects, but I wonder if there's a way to make it work with some creativity. For example you could have an outer Cargo.toml that does declare a workspace, and import miri as a subdirectory into the Rust tree (so the Rust tree never sees miri as a workspace, just as a crate).

[RalfJung]

The subtree approach we are working doesn't let us do that I think. This repo here is basically just a projection of the src/tools/miri subdir in the rustc repo -- the projection is deterministic so each time we extract we get matching git history. But I don't think we can have stuff "around" the projection. Everything in this repo must also exist in the rust repo.