test-merge-tools: introduce a "revision 4" that merges with conflict

We need conflicts to test the premerge=keep configuration.
mergetools: add a test for premerge --keep

It works! No surprise.
merge-tools: make premerge valid values extensible

We want to introduce a version leaving merge3 style markers.
merge-tools: add a `premerge=keep-merge3` config option

This value leaves premerge markers that includes the merge base too. This is a
the same as what `internal:merge3` would do.
push: explicitly encode a list of obsmarkers to push

Sending obsmarkers through pushkey requires extra encoding (since pushkey can't
take binary content) and slicing (since we can hit http header limit). As we
send all obsolescences markers that exists in the repo for each push, we used to
just look at the content of the "obsolete" pushkey namespace (already encoded
and sliced) and send its
content.

However, future changeset will make it possible to push only parts of the
obsmarkers. To prepare this we now explicitly encode a list of markers. The list
of markers is still "all of them" but future changeset will takes care
of that.

The new code uses a "_protected" method but that seems reasonable to keep it
private as this is the is the only external user of it and this whole pushing
obsmarker through pushkey things in fairly hacky already)
push: move the list of obsmarker to push into the push operation

The list is now carried in the push operation, this will let
extensions override it.
push: introduce a discovery step for obsmarker

The discovery step is still not doing anything smart. But this will allow
extension to wrap it.
push: use stepsdone for obsmarkers push

We do not have infrastructure to include obsolescence markers in the bundle2
push from core. But extensions may so we make sure it would not be sent twice.
config: fix restoreconfig of non existing config

When the section, but no value existed, the `del` call raised a key error.
rebase: do not retract phase boundary by hand

We rely on the internal mechanism to commit the changeset in the right phase.
This similar to what the mq extension is doing.

This is an important change as we plan to includes phase movement within the
transaction. Avoiding phase movement from high-level code will avoid the
burden of transaction handling. It is also important to limit the need for
transaction handling as this limits the odds of people messing up. Most common
expected mess-up is code using a different transaction for changeset creation
and phase adjustment.
commit: update the --secret code to use backupconfig and restoreconfig

Those dedicated methods also preserve all associated data (eg:
sources, lack of value).

--HG--
extra : amend_source : 4dcded281c0db1c50c7b60b3e93a86b56505f247
shelve: do not retract phase boundary by hand

We rely on the internal mechanism to commit the changeset in the right state.
This is similar to what the mq extension is doing.

This is an important change as we plan to move phase movement with the
transaction. Avoiding phase movement from high level code will avoid them the
burden of transaction handling. It is also important to limit the need for
transaction handling as this limits the odds of people messing up. Most common
expected mess-up is to use a different transaction for changesets creation and
phase adjustment.

--HG--
extra : amend_source : 23cd1788937cb119fe9b2c2e3d3c9cade9898627
changegroup: add a `targetphase` argument to `addchangegroup`

This argument controls the phase used for the added changesets. This can be
useful to unbundle in "secret" phase as required by shelve.

This change aims at helping high-level code get rid of manual phase
movement. An important milestone for having phases part of the transaction.
shelve: use `targetphase` while unbundling

This removes the last manual phase movement in shelve.
contrib: add check-commit hook script to sanity-check commits