Rework cargo-test-support & testsuite to use CARGO_BIN_EXE_* for Cargo

[ranger-ross]

What does this PR try to resolve?

This PR reworks cargo-test-support and testsuite to use Snapbox's cargo_bin!() instead of cargo_bin() which makes assumptions about the structure of Cargo's build directory.
cargo_bin!() uses CARGO_BIN_EXE_* for locating the cargo binary which should be more resilient to directory/layout changes.

Linking a relevant Zulip discussion here#t-cargo > cargo_bin_exe and tests

As shown in that link, we could make these variables available at runtime and not need to do this. However, cargo-test-support, as an API, is a bit weird in that it is baking in support for one specific binary. This can be confusing for callers and makes it more annoying for callers provide their own fn cargo, e.g. see crate-ci/cargo-fixit#7

Implementation Notes

cargo_bin!() only works when being called from the testsuite as it's only set when executing integration tests and cargo-test-support is a regular crate.
To make this change, I introduced an extension trait CargoProjectExt in testsuite for running .cargo() and implemented it on Project.

In cargo-test-support other functionality relies on .cargo() so these also needed to be moved to testsuite

• src/tools.rs
• Parts src/cross_compile
  • I had to split this up unfortunately, as disabled() requires running Cargo to check if we should disable cross compile tests.
  • Other fns in cross_compile are used in cargo-test-support so moving everything to testsuite would have ended up requiring moving many things to test suite.

How to test and review this PR?

I'd definitely recommend reviewing commit by commit.
There are a lot of diffs due to the nature of reorganizing things.
I did my best to split things things into smaller PRs but they still contain a lot of use statement diffs.

r? @epage

[epage]

Would prefer for these not to be ignore

[ranger-ross]

The issue is that these example use .cargo() which is no longer callable in cargo-test-support. So the example no longer compiles

Perhaps, we can keep it no_run if we comment (or remove) the .cargo() calls from the examples.

Maybe something like this for publish.rs

//! let registry = RegistryBuilder::new().http_api().http_index().build();
//!
//! let p = project()
//!     .file(...)
//!     .file("src/main.rs", "fn main() {}")
//!     .build();
//!
//!  // p.cargo("publish --no-verify")
//!  //   .replace_crates_io(registry.index_url())
//!  //   .run();
//!
//! validate_upload(
//!     r#"...."#,
//!     "foo-0.0.1.crate",
//!     &["Cargo.lock", "Cargo.toml", "Cargo.toml.orig", "src/main.rs"],
//! );

[epage]

Either that or we could ust do:

//! validate_upload(
//!     r#"...."#,
//!     "foo-0.0.1.crate",
//!     &["Cargo.lock", "Cargo.toml", "Cargo.toml.orig", "src/main.rs"],
//! );

[epage]

Should we put this in a prelude and maybe re-export cargo_test_support::prelude::* in it?

[epage]

That could even be done as a refactor commit before any of the other changes

[ranger-ross]

sure, that was something I was considering but didn't end following through with.

I think its a good idea.

[epage]

Also, we should probably check how https://doc.crates.io/contrib/tests/writing.html needs to be updated

[epage]

whats this blank line that got added to a lot of these files?

[epage]

Can you split out the creation of CargoProjectExt from the prelude, as in create the prelude in one commit and then CargoProjectExt after it?

This touches a lot of files and so being minimal with what is changed can make it a lot easier to review or come back later and see what was done

See also #15692 (comment)

[epage]

This commit seems to have some unrelated changes in it

[epage]

Why is the use added when its in the prelude?

[ranger-ross]

Okay sorry, I cleaned up the commits. (Not quiet sure what happened)

I split out the commits as you suggested in this comment and updated the testing documentation as well