refactor: Pull out cargo-add MSRV code for reuse
### What does this PR try to resolve?
#12078 added MSRV code in `cargo add`. Our assumption when writing it is that we'd need to generalize the code before reusing it in other places, like `cargo install`. This PR focused purely on that refactor because I'm hopeful it will be useful for other work I'm doing. Despite not having a user for this yet, I think the `cargo install` case is inevitable and I feel this does a bit to clean up MSRV related code by using a more specific type everywhere.
### How should we test and review this PR?
Each commit gradually progresses things along
This changes logged messages from
```
2023-08-23T01:01:59.922018Z DEBUG cargo::core::compiler::fingerprint: filesystem up-to-date "/home/epage/src/personal/dump"
```
To
```
0.041729583s DEBUG cargo::core::compiler::fingerprint: filesystem up-to-date "/home/epage/src/personal/dump"
```
Benefits
- Less horizontal space taken up in boilerplate
- Easier to compare within a run
Downsides
- Harder to correlate with other processes, like with crates.io server
operations
This gives us up to 4 digits for seconds which should be sufficient for
cargo build times.
We could make this more compact by dropping the digits of precision from
9 to 6 but that would require a custom Timer which might be a paint to
keep in sync between packages.
versions and paths of a workspace members between the original and
a checked-out workspace are different, and shouldn't be included in
hash keys when querying packages.
ci: rewrite bump check and respect semver
### What does this PR try to resolve?
This ports `ci/validate-version-bump.sh` and #12200 to the new xtask `bump-check`. It also adds the ability to set the correct baseline revision when checking version bump. That is, it fixes#12347.
In addition, this integrates the community tool `cargo-semver-checks`. SemVer violation can now be detected earlier.
### How should we test and review this PR?
This PR extracts the registry query part from `xtask-unpublished` and removes other pars. I don't feel like we need it in the short term.
For how it works, please the check doc comment in each function.
One concern is that this check is still a required job for bors. I believe `@obi1kenobi` is quite responsive and willing to help if there is something wrong. So, waiting for an upstream fix won't be a problem for cargo. Also as a good citizen in the community, we can always contribute back.
(Take it easy `@obi1kenobi,` don't be stressed out 🙂)
<!-- homu-ignore:end -->
fix: AIX searches dynamic libraries in `LIBPATH`.
### What does this PR try to resolve?
On IBM AIX machines people have encountered issues in `compiletest` and rustc's bootstrap builder. They haven't encountered any in cargo. This PR is made for avoiding potential failures in the future in cargo.
It's documented in <https://www.ibm.com/support/pages/libpath-environment-variables-aix-platforms>:
> The `LIBPATH` environment variable tells AIX applications where to find shared libraries when located in a different directories than those specified in the header section of the executable.
See also the counterpart in <https://github.com/rust-lang/rust/pull/109526>
### How to verify and test this in Cargo's CI?
This is indeed an issue. At IBM people are maintaining a buildbot since GitHub Action doesn't support AIX yet.
ci: check if any version bump needed for member crates
### What does this PR try to resolve?
Check if a crate requires a version bump in CI.
Part of #12033
### How should we test and review this PR?
Demo action result: <https://github.com/weihanglo/cargo/actions/runs/4941952784/jobs/8835049007>
### Additional information
This doesn't devalue #12089. I love the changelog detection, saving maintainers' times a lot ( I am the one writing changelogs for each release for now). However, the amount of code there is too excessive to me. I think someday when we are going to integrate [cargo-release](https://crates.io/crates/cargo-release) and/or [ehuss/cargo-new-release](https://github.com/ehuss/cargo-new-release), we can remove this script perhaps entirely :)
I tried to document the script a bit hard. Hope it won't get worse over time.
