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.