shelve: use `targetphase` while unbundling This removes the last manual phase movement in shelve.

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: 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.

commit: update the --secret code to use backupconfig and restoreconfig Those dedicated methods also preserve all associated data (eg: sources, lack of value).

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.

config: fix restoreconfig of non existing config When the section, but no value existed, the `del` call raised a key error.

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.

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: 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: 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)