phases: test phases tracking at the transaction level Now that we have all tracking in place, the data in `tr.changes['phases']` dictionary should be correct and we should test it. It is a bit late in the cycle to discuss to add any public API (eg: hooks) that expose the data to the user, so we just add a small test extension displaying the data. It is enabled for the phases tests. New output have been manually checked for consistency.

phases: track phase changes from 'retractboundary' We adds new computation to find and record the revision affected by the boundary retraction. This add more complication to the function but this seems fine since it is only used in a couple of rare and explicit cases (`hg phase --force` and `hg qimport`). Having strong tracking of phase changes is worth the effort.

phases: detect when boundaries has been actually retracted It is useful to detect noop and avoid expensive operations in this case. We return the information to inform the caller of a possible update. Top level function might need to react to the phase update (eg: invalidating some caches, tracking phase change).

phases: rework phase movement code in 'cg.apply' to use 'registernew' We rework the code to call 'registernew' before any other phase advancement. This make 'changegroup.apply' register correct phase movement for the added and bundled nodes.

convert: use the new 'phase.registernew' function

localrepo: use the 'registernew' function to set the phase of new commit

phases: add a 'registernew' method to set new phases This new function will be used by code that adds new changesets. It ajusts the phase boundary to make sure added changesets are at least in their target phase (they end up in an higher phase if their parents are in a higher phase). Having a dedicated function also simplify the phases tracking. All the new nodes are passed as argument, so we know that all of them needs to have their new phase registered. We also know that no other nodes will be affected, so no extra computation are needed. This function differ from 'retractboundary' where some nodes might change phase while some other might not. It can also affect nodes not passed as parameters. These simplification also apply to the computation itself. For now we use '_retractboundary' there by convenience, but we may introduces simpler code later. While registering new revisions, we still need to check the actual phases of the added node because it might be higher than the target phase (eg: target is draft but parent is secret). We will migrate users over the next changesets.