push: only push obsmarkers relevant to the "pushed subset" We should only exchange obsolete markers related to the changesets that are being exchanged. For example, if `A'` is a successor of `A`, we do not want to push the marker if we are not exchanging `A'`. Otherwise `A` would disappear without a successor, leading to confusion for both users and the evolution mechanism. Therefore we now exchange only the markers relevant to the subset of nodes involved in the push (the nodes themselves may be already common but were selected by --rev (or the lack of --rev)). Note that all selected markers are still exchanged on each push. We do not have a discovery protocol for markers in core yet. Such discovery would save us the exchange of markers known on both side.

test-obsolete: sort the output of debugobsolete The set of relevant markers is currently unordered. Therefore the markers will be added in arbitrary order. We sort the list of markers beforehand to ensure stable output for testing.

test-obsolete: change a marker so it is relevant to the exchanged set We are going to only exchange markers relevant to the exchanged changesets. So we need to change this marker to use a known changeset as a successor instead of a precursor.

push: use bundle2 to push obsmarkers when possible

exchange: add a `buildobsmarkerpart` function We'll have to build an obsmarker part for both push and pull. So we build a function to factor out the common part.

obsolete: add a `commonversion` function This function returns the highest common version between the locally known formats and a list of remotely known formats. This is going to be useful to know what format should be used for exchange.

bundle2: add a `obsmarkersversion` function to extract supported version Right next to the function that encodes the supported versions in capabilities we add a function that decodes the versions out of capabilities. This is going to be useful to know what formats can be used for exchange.

bundle2: advertise the obsmarker part in bundle2 capabilities

bundle2: introduce a `getrepocaps` to retrieve the bundle2 caps of a repo This function lets extensions change the bundle2 capabilities of a repository.

obsmarker: move bundle2caps from the localrepo class to the bundle2 module The localrepo path was quicker, easier, more seductive. We'll soon add a function in another changeset to alter the capabilities.