peer: add a `path` attribute to peer It will start being set in the coming changesets.

peer: have a common constructor and use it For now it does not do much, but we will extend it to also store a path object soon.

peer: use a dedicated name for the `peer` constructor We want to change the argument it takes, so we rather make them different function.

peer: dissolve `_peerlookup` into its last two callers This is about to need more changes and the function won't be useful. We do it early to clarify later changes.

peer: stop having a `peer()` method on `peer()` This is already a peer, why do you want a peer if you already have one.

clone: explicitly detect the need to fetch a peer Instead of having `peer()` method on all `peer()` for this usecase, we could simply handle it explicitly.

addbranchrevs: explicitly detect the need to fetch a peer Instead of having `peer()` method on all `peer()` for this usecase, we could simply handle it explicitly.

path: pass `path` to `peer` in `hg clone` We directly use the `path` object to build the `peer` object.

path: use `get_clone_path_obj` in share The return is simpler to use, and this mean less user for the old function. We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in mq We directly use the `path` object to build the `peer` object. There is one case where we don't. We should fix that at the same time as we fix the sub-repo cases.

path: use `get_clone_path_obj` in _getlocal We don't need to feed the `path` object to a `peer` object, but using an higher level function is simpler here (e.g. no subscript access, explicit attribute access).

path: pass `path` to `peer` in `hg init` We directly use the `path` object to build the `peer` object.

path: add a `get_clone_path_obj` function Same logic as the `get_unique_pull_path_obj` function, this give access to the `path` object directly.

path: simplify the implementation of `get_clone_path` We can simply use the logic from `get_unique_pull_path_obj` now.

path: clarify document of `get_clone_path` This return a url as `bytes`, not a `path` object.

path: pass `path` to `peer` in `hg perf::discovery` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in remotefilelog's tests We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg fastannotate` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in infinitepush We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in largefiles We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in narrow We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg fetch` We directly use the `path` object to build the `peer` object.

path: use `get_unique_pull_path_obj` in `hg relink` This is not really needed, but that help removing caller of the older function.

path: pass `path` to `peer` in `hg transplant` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg debugbackupbundle` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg debugssl` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg debugdiscovery` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `remote(...)` revset We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg summary` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg identify` We directly use the `path` object to build the `peer` object.

path: introduce a `get_unique_pull_path_obj` function Unlike the previous one, `get_unique_pull_path`, this function return the `path` object, opening more option for the caller. note that this highlight we don't actually need the `repo` argument to `get_pull_paths`, however changing the API would be annoying for third party extensions.

path: simplify the `get_unique_pull_path` function Simply delegate the search to `get_pull_paths` and check how many we got.

path: remove outdated documentation point from `get_unique_push_path` This is no longer true.

path: pass `path` to `peer` in `hg pull` We directly use the `path` object to build the `peer` object. We don't use it for sub-repositories yet, which will have to be fixed at some point.

path: pass `path` to `peer` in `hg incoming` We directly use the `path` object to build the `peer` object. We don't use it for sub-repositories yet, which will have to be fixed at some point.

path: pass `path` to `peer` in `hg incoming` bookmark logic We directly use the `path` object to build the `peer` object. Touching this code highlighted that we never honor the branches' information of when doing bookmark level incoming checks.

path: remove outdated documentation point from `get_unique_pull_path` This is no longer true.

path: update `get_unique_pull_path` to point out it returns a url Unlike other functions in this module it returns a url as `bytes` and not a `path` object. Let us point it out in the doc.

changelog-v2: fix the docket `struct` The previous definition used `L` which is actually 4 bytes, while the documentation and intend was to use `Q`, i.e. 8 bytes.

path: pass `path` to `peer` in infinite push We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg histedit` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in the `outgoing` revset We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg summary` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg outgoing` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg bundle` We directly use the `path` object to build the `peer` object.

path: have `peer` constructor accept a `path` object We don't do anything fancy with it yet, but this is an important step towards having the peers aware of their "source" and associated configurations.

path: deprecated the `pushloc` attribute We want to make sure people with use the full featured path "variant".

path: update logic in `perf` to use the push variant when available The command seems currently broken, but at least it won't be broken by us !

path: directly use the push_variant in `infinitepush` We don't need any extra processing now.

path: directly use the push_variant in `hg histedit` outgoing logic We don't need any extra processing now.

path: directly use the push_variant in the `outgoing` revset We don't need any extra processing now.

path: directly use the push_variant in outgoing internals We don't need any extra processing now.

path: directly use the push_variant in `hg summary` We don't need any extra processing now.

path: directly use the push_variant in `hg outgoing` We don't need any extra processing now.

path: directly use the push_variant in `hg push` We don't need any extra processing now.

path: have `get_push_paths` directly return the push variants So the function directly returns usable paths, that should help the callers!

path: add a method to retrieve a "push variant" of a path This gets you the same path, but using the `pushurl` as destination. This opens the way for a lot of different improvements, the one which interests us is having `peer` objects aware of the `path` they came from.

path: move the url parsing and related attribute setting to a method This will make it simpler to reuse this logic in the next changeset.

peer-or-repo: remove the now unused function We do not need it anymore.

peer-or-repo: build a repo directly in the `repo` function We skip the ambiguous _peerorrepo function to explicitly build a repo within the dedicated function. The peer scheme are therefore no longer considered to build the object.