peer: rename makepeer() → _make_peer() In httppeer and sshpeer, there previously were makepeer() and make_peer(), which was confusing. Therefore, this changeset renames one of the functions. makepeer() was the internal function called by make_peer() and some debug command. This function is renamed to _make_peer().

rust: configure MSRV in Clippy This setting makes Clippy never apply lints that are meant for later versions. In case the target precise toolchain is the one running, it does not make a difference, but this gives us a machine-parseable specification that is pretty standard. The README and `hg help rust` are updated to state that `clippy.toml` is the single source of truth about that, also lifting a minor ambiguity: it is fine if the MSRV is lagging behind the version in Debian testing.

rust-readme: mentioned that format check is enforced by CI

rust-readme: mentioning clippy especially since there is a CI check for it.

rust-readme: rst fixes

chg: populate CHGHG if not set Normally, chg determines which `hg` executable to use by first consulting the `$CHGHG` and `$HG` environment variables, and if neither are present defaults to the `hg` found in the user's `$PATH`. If built with the `HGPATHREL` compiler flag, chg will instead assume that there exists an `hg` executable in the same directory as the `chg` binary and attempt to use that. This can cause problems in situations where there are multiple actively-used Mercurial installations on the same system. When a `chg` client connects to a running command server, the server process performs some basic validation to determine whether a new command server needs to be spawned. These checks include things like checking certain "sensitive" environment variables and config sections, as well as checking whether the mtime of the extensions, hg's `__version__.py` module, and the Python interpreter have changed. Crucially, the command server doesn't explicitly check whether the executable it is running from matches the executable that the `chg` client would have otherwise invoked had there been no existing command server process. Without `HGPATHREL`, this still gets implicitly checked during the validation step, because the only way to specify an alternate hg executable (apart from `$PATH`) is via the `$CHGHG` and `$HG` environment variables, both of which are checked. With `HGPATHREL`, however, the command server has no way of knowing which hg executable the client would have run. This means that a client located at `/version_B/bin/chg` will happily connect to a command server running `/version_A/bin/hg` instead of `/version_B/bin/hg` as expected. A simple solution is to have the client set `$CHGHG` itself, which then allows the command server's environment validation to work as intended. I have tested this manually using two locally built hg installations and it seems to work with no ill effects. That said, I'm not sure how to write an automated test for this since the `chg` available to the tests isn't even built with the `HGPATHREL` compiler flag to begin with.

run-tests: remove obsolete coverage check and packaging import (issue6805) This removes an obsolete `coverage` version check (version from a decade ago). This also conveniently removes the dependency over `packaging.version`, which requires some additional installation since Python 3.10.

test-tx-rollback: more lenient glob for kill status (issue6807) The "killed" message may have some prefix and/or suffix which differ depending on the platform. This makes the pinned test output more lenient to accept those.

rustdoc: nodemap doc refreshing Not pretending to be comprehensive. - correcting some inconsistencies - adding a few missing doc-comments - adding more cross references (in some cases it's right beside the current documentation item, but it will nevertheless also be useful, because `rustdoc` will warn us if inconsistencies arise).

rustdoc: fixed or introduced crossrefs in nodemap.rs