test: add a push race case where non-contiguous branch head are created We check case where the raced push an update to branch default head while the racing push update that same head but through another named branch.

test: add a push race case where the raced push touch multiple heads We check case where the raced push update all heads while the racing push update one of them.

test: add a push race case where racing push touches multiple heads We check case where the raced push updates a head while the racing push update all of them.

test: add a push race case where racing push create a new named branch This is the mirror case from the previos one. We check case where the raced push update a head while the racing push create a new named branch as a children of that updated head.

test: add a push race case where raced push created a new named branch We check case where the raced push create a new branch on the same head updated by the racing push.

test: add a push race case where the racing client create a new head We check case where the raced client push updates an existing head while the racing client push creates a new one.

test: add a push race case where each client replaces a different head We check case where the raced push replace one head while the racing push replaces another unrelated one. That second test also make sure we synchronise all repositories to the same state between tests. That will help us when allowing some sort of concurrent pushes.

test: add a file dedicated to push race between clients There are very few tests around the detection of push race. This file will be dedicated to covering these cases more through fully. We start with a simple case. More complex cases get added in later changesets. My end goal here is to provide a way for server to accept concurrent push as long as they are not touching the same heads. However, I want to buff the test coverage of that code before touching anything.

strip: strip obsmarkers exclusive to the stripped changeset This is it, `hg strip --rev X` will now also remove obsolescence markers exclusive to X. Since a previous changeset, the obsmarkers has been backed up in the strip backup bundle, so it is possible to restore them. Note: stripping obsmarkers means the precursors of the stripped changeset might no longer be obsolete after the strip. Stripping changeset without obsmarkers can be useful when building test case. So It is possible to disable the stripping of obsmarkers using the 'devel.strip-obsmarkers' config option. Test change have been carefully validated.

strip: do not include obsolescence markers for the temporary bundle When stripping, we need to put all non-stripped revisions "above" the stripped ones in a "temporary-bundle" while we strip the targets revision. Then we reapply that bundle to restore these non-stripped revisions (with a new revision numbers). We skip the inclusion of obsolescence markers in that bundle. This is safe since all obsmarkers we plan to strip will be backed-up in the strip backup bundle. Including the markers would create issue in some case were we try to strip a prune markers that is "relevant" to a revision in the "temporary-bundle". (note: we do not strip obsmarkers yet)