stream-clone: bail-out earlier if destination repo is not empty The `canperformstreamclone` function is bit messy. However it seems clearer to me to process the very generic condition about "can we consider a stream-clone at all", before checking if a stream-clone is requested and if a compatible protocol can be negotiated with the server. So I am doing some gratuitous movement so reorder conditional.

stream-clone: check the version of streaming clone supported by the client Make the server refuse to produce streaming clone bundle, if the client doesn't specify the stream=v2 capability. This is in preparation to introduce stream=v3. As far as I can tell, this capability was added at the same time as support for bundle2-based streaming pulls was added, so I don't expect clients to break. (the modern client doesn't break, at any rate)

stream-clone: make sure the `stream` capability is set when bundling This is important to start narrowing protocol option in the next changesets.

stream-clone: upgrade the error message for bad stream request The new version if more compact and more consistent with the general Mercurial usage.

stream-clone: yield cache entry in `_entries_walk` too The new function now cover the same ground as _v2_walk.

stream-clone: introduce a _entries_walk That function insert itself between the store and `_v2_walk`. It only deals with StoreEntry unlike `_v2_walk` that deal with actual file. A share of the `_v2_walk` logic will be moved in this new `_entry_walk` function. Having this function will help us to implement a new "v3" version of the protocol that will be more entry centric.

store: make `walk` return an entry for obsolescence if requested so Instead of having dedicated code in the streamclone code, we should have the store deal with advertising the data it contains.

store: yield phases before changelog Creating the `changelog.i` file make the repository usable, so dealing with phase earlier seems better.

store: make `walk` return an entry for phase if requested so Instead of having dedicated code in the streamclone code, we should have the store deal with advertising the data it contains.

cli: add a test of `hg debugnodemap --manifest` this is a new option that's not tested yet

cli: fix spelling in `debugnodemap` error messages

cli: make debugnodemap capable of inspecting an arbitrary nodemap This lets us inspect the manifest nodemap and individual directory nodemaps when treemanifest is used.

rust: mostly avoid streaming zstd decompression Streaming ZStd decompression seems slightly slower, and the API we use makes it very inconvenient to re-use the decompression context. Instead of using that, use the buffer-backed version, because we can give a reasonable-ish size estimate.

rust: in zstd decompression, avoid a useless vec initialization

rust: speed up zstd decompression by re-using the decompression context Admittedly, zstd is already pretty fast, but this change makes it a bit faster yet: it saves ~5% of time it takes to read our large repo. The actual motivating use case is treemanifest: in treemanifest we end up reading *lots* of small directories, and many of them need decompression, and there the saving for [rhg files] is >10%. (which also seems unreasonable, we should probably keep things uncompressed more)

store: rename `topfiles` to `top_entries` The method is now returning StoreEntries let us rename the method for clarity.

store: rename `datafiles` to `data_entries` The method is now returning StoreEntries let us rename the method for clarity.

store: use boolean property for upgrade's matchrevlog

store: use the new boolean property in `upgrade`

store: use the new boolean property in `remotefilelogserver`

store: use the boolean property in `repair_issue6528`

store: use the new boolean property in `narrow`

store: use the boolean property in `store`

store: introduce boolean property for revlog type This will avoid exposing implementation details to more generic code.