Add local registry overlays
This PR adds (private to cargo internals) support for local registry overlays, in which you can locally pretend to add packages to remote registries; the local packages will have the same source ids as the remote registry that you're overlaying.
There are two ways to set up these overlays: programmatically using `GlobalContext::local_overlays` and through the `__CARGO_TEST_PACKAGE_CONFUSION_VULNERABILITY_DO_NOT_USE_THIS` environment variable. You can't set up these overlays with `.cargo/config`.
The motivation for this is [packaging workspaces](https://github.com/rust-lang/cargo/issues/10948). When we're packing a workspace, we'd like to be able to pretend (for lockfile generation and verification) that some workspace packages are already published even though they aren't.
While this is noisy and hides other deprecations, I figured deprecations would
make it easier for people to discover what tasks remain and allow us to
divide and conquer this work rather than doing a heroic PR.
In theory, this will be short lived and we'll go back to seeing
deprecations in our tests.
refactor: Transition direct assertions from cargo-test-support to snapbox
### What does this PR try to resolve?
Cargo has a bespoke testing framework for functional tests
- Extra stuff for us to maintain
- Don't leverage benefits from contributions related to other projects
- Less incentive to be thoroughly documented
UI tests are written using snapbox. The latest release of snapbox (#13963) was geared at supporting cargo's needs in the hope that we can consolidate on testing frameworks.
Besides having a single set of semantics, benefits we'd gain include
- Updating of test snapshots
- Fancier redacting of test output (e.g. #13973)
This is the first incremental step in this direction. This replaces direct assertions with snapbox assertions. This still leaves all of the CLI output assertions. These will be done incrementally.
### How should we test and review this PR?
### Additional information
They are still nominally gzipped, but using `Compression::none()` makes
them consistent even across zlib and zlib-ng, and this fixes checksum
differences in the testsuite. There is a one-time update of all those
checksums to catch up with this change though.
This uses a new feature from snapbox that let's us render terminal
styling in SVG files. This let's us see / visualize ANSI escape codes,
including in github's UI (will render images, including side-by-side
images for diffs).
Add global_cache_tracker stability tests.
This adds some tests to ensure that the database used in the global cache tracker stays compatible across versions. These tests work by using rustup to run both the current cargo and the stable cargo, and verifying that when switching versions, everything works as expected.
These tests will be ignored on developer environments if they don't have rustup, or don't have the stable toolchain installed. It does assume that "stable" is at least 1.76. It is required for the tests to run in CI, but will be disabled in rust-lang/rust since it does not have rustup.
I'm not expecting too much trouble with these tests, but if they become too fiddly or broken, they can always be changed or removed.
The support code for running "cargo +stable" is very basic right now. If we expand to add similar tests in the future, then I think we could consider adding support functions (such as [`tc_process`](64ccff290f/tests/testsuite/old_cargos.rs (L21-L36))) to make it easier or more reliable.
This has bothered me about `cargo new` and `cargo init` for a while that
the output is read backwards, for example:
```diff
--- i/tests/testsuite/cargo_init/path_contains_separator/stderr.log
+++ w/tests/testsuite/cargo_init/path_contains_separator/stderr.log
@@ -1,3 +1,3 @@
+ Creating binary (application) package
warning: the path `[ROOT]/case/test:ing/.` contains invalid PATH characters (usually `:`, `;`, or `"`)
It is recommended to use a different name to avoid problems.
- Created binary (application) package
```
