localrepo: enforce a clean dirstate when the transaction open This is important to simplify the backup process. This also seems like a quite reasonable expectation. See inline documentation for details.

dirstate: explicitly backup the datafile Since the transaction does not know about this file, we need to explicitly mark it for backup before touching it.

mq: write the dirstate before stripping I am not certain why it is dirty (probably the `repo.setparent` call a right before. However I know we need it flushed before the repository starts to be stripped.

dirstate: simplify the shelve hack to not go through the disk We already have the data in memory, so why not simply keep the data in memory? This avoid abusing the `savebackup/restorebackup` logic and will make our life easier.

dirstate: detect potential fishy transaction patterns while changing If we rely on the transaction more, we should be more careful about the transaction. Adding extra security seems reasonable.

dirstate: generalize the dirstate's invalidation on transaction abort The previous code was too specific, we should add the invalidation at next to the `addfilegenerator` in the `write` call.

dirstate: simplify some methods' decorator Since `changing_parents` and `changing_files` are mutually exclusive, having both `@requires_changing_files` and `@requires_not_changing_parents` on a method is redundant.

dirstate: document the functions that need consolidation They are more functions that make the dirstate dirty but does not currently enforce a clean change scoping, we add comments in front of each of them so clarify this. There is no urgency to it, but the world will be a better place when all of them have proper scoping in place.

dirstate: make `restorebackup` more robust when it is a noop If there are no data_file, we might not be able to determine its filename. Which can be safely ignored. (all this code is on the way out anyway)

dirstate-guard: remove the feature The dirstate guard duplicated some of the logic already implemented in the transaction (and now the changing_* context). However the feature was incomplete, for example, living only in memory meant we could not recover from the hardest crash. In addition this duplicated with the transaction logic meant things could go out of sync or step on each other. Removing the feature now that we no longer needs it seems the safest.