hidden: add support for --remote-hidden to HTTP peer Test written by Pierre-Yves David.

hidden: add support to explicitly access hidden changesets via HTTP We now detect hidden access request and validate them while handling HTTP wireprotocol command. This changeset only introduces server support. Client support is added in a subsequent changeset. The mechanism we use for the HTTP wireprotocol is the same as the one used to lift filtering for hgweb. The use of the global `access-hidden` parameter in the http url is a simple and effective approach that * works around the lack of global parameters in wire protocol v1, * reuses the mechanism used for hgweb (that does not use the wireproto), and * can be safely ignored by older client (fitting the best effort contract). The feature is still experimental, so we can easily update the implementation details in the future. However, landing a first implementation now will help test the feature in the wild and iterate on alternative implementations if deemed necessary.

hidden: support for explicitly accessing hidden changesets in wireproto server This installs the basic infrastructure to be able to access hidden changeset through the wireprotocol. Each wireprotocol server still needs a way to define how the feature is triggered.

hidden: add support for --remote-hidden to localpeer

pull: add --remote-hidden option and pass it through peer creation This option will allow to pull changesets that are hidden on the remote. This is useful when looking into a changeset’s evolution history, resolving evolution instability or mirroring a repository. The option is best effort and will only affect the pull when it can. The option will be ignored when it cannot be honored. Support for each type of peer is yet to be implemented. They currently all warn about lack of support. The warning code will get removed as peers gain support for this option. The option is still experimental, so we will have freedom to update the UI or implementation before it graduates out of experimental. Based on a changeset by Pierre-Yves David, which added the option.

hgweb: add support to explicitly access hidden changesets This changeset adds a "global" `access-hidden` argument to hgweb. This argument lift the "hidden" filtering. This means the request has access to hidden (eg: obsolete) changesets. Secret changesets remains filtered. This feature has multiple applications. The first main use case is to allow the hgweb interface to display more obsolescence related data, such as the Anton Shestakov work to add `obslog` support to hgweb. The second foreseen usecase is support for a `--remote-hidden` argument to `hg pull` and `hg clone`. This flag will make it possible to retrieve hidden (typically obsolete) changeset under some conditions. This is useful when digging up obsolescence history or when doing full mirroring. More on this feature coming in later changesets. To avoid exposing information by mistake, access to this feature is currently controlled with the `experimental.server.allow-hidden-access` config option. The option works the same way as `web.allow-push`. The current default is to not allow any hidden access. However we might change it before the feature stop being experimental.

clone-bundles: add an option to generate bundles in the background This is what the "on-change" version have been doing from the start, it seems useful to also offer this option in the command.

clone-bundles: add a command to clear all bundles

clone-bundles: add more test cases for automatic generation See inline documentation for details.

clone-bundles: introduce a command to refresh bundle This command allows for a different mode than the one attached to the transation. It might fit some hosting setup better.

clone-bundles: add a configuration to control auto-generation on changes We are about to introduce a "manual" way to deal with automatic clone management but running a command using some internal API. The first step is to introduce a way to control the "on changes" behavior.

clone-bundles: also control automation based on absolute number of revisions

clone-bundles: only regenerate the clone bundle when cached ration is low See inline documentation for details.

clone-bundles: garbage collect older bundle when generating new ones See inline documentation for details.

clone-bundles: add a basic first version of automatic bundle generation See inline documentation for details.

branching: merge stable into default

tests: automatically glob the discovery timing information Time is not stable in tests.

rhg: support `status --print0` This seems very easy to support, and useful because it makes it possible to parse the [hg status] output even if the user creates files with '\n' characters by accident.

stabletailgraph: implement stable-tail sort This adds the computation of the "stable-tail sort", an incremental node sorting method. It is a stepping stone for the implementation of faster label discovery (for example for obs markers) and more caching.

heptapod: add `.gitattributes` file to improve language detection I am fully aware of the irony.

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.