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
Falling back to hard_link when that happens, retrying can lead to very
long wait before copying works (up to 4secs in my tests) while
hard_linking works straight away.
Looks related to https://github.com/openzfsonosx/zfs/issues/809Closes#13838
We allowed `[badges]` to inherit from `[workspace.package.badges]`
This was a bug:
- This was not specified in the RFC
- We did not document this
- Even if someone were to try to guess to use this, it is inconsistent
with how inheritance works because this should inherit from
`workspace.badges` instead of `workspace.package.badges`
While keeping in mind that `[badges]` is effectively deprecated.
In that context, I think its safe to break support for this without a
transition period.
Fixes#13643
We already only partially check it and it has been a source of false
positives.
While there is trust in the job, contributors and maintainers go into
the job assuming there is a problem and it takes time to break that
assumption.
If we lose trust in the job, we then won't trust it when it fails for
other reasons.
This also increases the risk of us not seeing other problems
`bump-checks` is meant to find if the steps in the job get re-arranged
to make this one of the early ones.
Cleanup linting system
There are a number of problems with the current linting system, most notably that lints could run without `-Zcargo-lints` being set. This PR fixes that issue and a few others that are low-hanging fruit.
gate some libc usages under cfg(unix), drop os_info features
Places few `libc` usages under `cfg(unix)`. That didn't remove it from tree, but still looks cleaner.
Drop features from os_info crate, as serde support currently unused.
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 assumes that if any of the machine applicable fixes in
a diagnostic suggestion is a duplicate, we should see the
entire suggestion as a duplicate.
