dirstate: explicitly write the dirstate after mq dirstate rebuild I am working on making the dirstate write patterns more predictable. This patch is part of a small series of similar patches that adds a explicit dirstate write in a handful of location where the dirstate is updated "a bit in a strange way". With this explicit write, we are no longer relying on implicite write of the dirstate on `wlock` release. This make the world a better place.

transaction: quietly rollback if no other changes than temporary files If no actual change have been made, we don't really need to roll them back. We only have to cleanup some temporary files and it seems reasonable to do that quietly. This will help us to use the transaction in wider context¹ without impacting the user experience. [1] as in Python context managers that lives longer.

transaction: run abort callback in all cases Previously, these possibly important callback were "forgotten" when running a quick rollback. This is now fixed, as the tests shown.

transaction: clarify the "quick abort" scenario Right now, the transaction has a code-pass to do a "quick abort" that skip most¹ (too much) of the logic when the right condition are detected² We are about to improve this logic in multiple aspect. We clarify the code first. The conditional return in `_can_quick_abort` looks a bit weird because we are about to make them more complex very soon. [1] actually too much [2] actually not often enough

test: use a more direct form of interruption in fncache "recover" testing The previous test was relying on implementation details and harder to maintain. The new version is closer to the initial intend : "What happens if the process die without cleanup". This change is motivated by further changes around the transaction and dirstate logic that would break the fragile equilibrium that existed before this patch. Making this change early make it easier to review on its own and remove noise in future larger changes.

test: use a more direct approach to test racy mutation The previous test was relying on implementation details and harder to maintain. The new version is closer to the initial intend : "What happens the file get overwritten from under the current process" This change is motivated by further changes around the transaction and dirstate logic that would break the fragile equilibrium that existed before this patch. Making this change early make it easier to review on its own and remove noise in future larger changes.