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.
Poll loop fixes
### What does this PR try to resolve?
A couple of minor issues. See individual commits.
### How should we test and review this PR?
The existing test suite should have sufficient coverage.
### Additional information
(I have 5 apparently unrelated failures locally when running `cargo test`)
Improve integration of the http server introduced by the http-registry feature.
Now the same HTTP server is used for serving downloads, the index, and
the API.
This makes it easier to write tests that deal with authentication and
http registries.
Mark .cargo/git and .cargo/registry as cache dirs
Fixes#10457
### What does this PR try to resolve?
As we previously discussed in #10457 this marks `~/.cargo/git` and `~/.cargo/registry` as not to be included in backups, and not subject to content indexing. These directories can be fairly large and frequently changed, and should only contain content that can be re-downloaded if necessary.
### How should we test and review this PR?
I did two manual tests:
1. Using the binary built from this tree, run `cargo update` in a source tree that has a git dependency, and observe that afterwards, there is a `CACHEDIR.TAG` in `~/.cargo/git`.
2. Similarly, run `cargo update` and observe that there's a `CACHEDIR.TAG` in `~/.cargo/registry`.
(I ran this on Linux. This code should also trigger OS-specific behavior on macOS and Windows that's the same as is currently applied to `target/`.)
I added some test assertions.
- Add `ProcessBuilder::output` and ProcessBuilder::status`, which are
unopinionated version of `exec_*` (won't error out when exitcode > 0)
- Add `ProcessBuilder::retry_with_argfile` to enable trying with argfile
when hitting the "command line too big" error.
Upgrade Cargo to the 2021 edition
While I was poking around in the manifests I also went ahead and removed the `authors` entries since at least the one for Cargo itself is quite outdated and Cargo otherwise doesn't use these any more.
