dirstate: do no use `set_clean` in revert The current `set_clean` usage is racy (the file might be modified between its restoration and the `set_clean` call). So we simply leave the file as ambiguous and the next status will fix that. We still have to make sure the copy information is dropped, so we teach dirstate how to do that. The win32txt extension is confused after this because current logic is broken in more location. However this series will ultimately fix that so we "ignore" it for now. Fixing it now is complicated without some extra fix landing later. Differential Revision: https://phab.mercurial-scm.org/D11788

status: adapt the "keyword" extensions to gather stats at lookup time See main core code for details. We don't factor the code in a common function yet, because we will have to adapt a bit more things in the keyword case at the end of the series. Differential Revision: https://phab.mercurial-scm.org/D11787

status: adapt largefile to gather stats at lookup time See the core code for details of why we are doing this. We don't factor the code in a common function yet, because we will have to adapt a bit more things in the largefile case at the end of the series. Differential Revision: https://phab.mercurial-scm.org/D11786

status: gather fixup info at comparison time This is still racy, but on a much small windows. In addition, the API now make it possible for it to not be racy. This also unlock other cleanups that we are about to do regarding mtime ambiguity at gathering time. Differential Revision: https://phab.mercurial-scm.org/D11785

update: filter the ambiguous mtime in update directly Right now, this filtering is done by `dirstate.write` using the time of `dirstate.write` method call. However that filtering is done "too late" It works "fine" as most command are "fast enough", and race rare enough. We are about to change the mtime filtering logic in the dirstate to be more accurate and reliable. However `hg update` will still need such filtering (mostly because it is actually quite racy, even with the existing filtering). So we explicitly implement a similar logic here. Before removing the older one later in the series. Differential Revision: https://phab.mercurial-scm.org/D11784

dirstate: move "get fs now" in the timestamp utility module We will need it during update. Differential Revision: https://phab.mercurial-scm.org/D11783

dirstate-item: allow mtime to be None in "parentdata" This will be useful to filter out unreliable mtime. Differential Revision: https://phab.mercurial-scm.org/D11782

dirstate: add a comment about a racy piece of code during updates This is a bit that is not really correct but works "fine" in practice. Let us write the details down so that people stop wondering how that logic might be correct… It is not. Differential Revision: https://phab.mercurial-scm.org/D11781

tests: add missing `head` for when things go wrong See comment above the changed line, you can get a millions of line of output in case of failure. When don't need to have them all. Differential Revision: https://phab.mercurial-scm.org/D11780

tests: ensure a status will have non ambiguous mtime in some race test For the test to work, we need some mtime to be recorded. For them to be recorded, they need to be "clearly in the past", otherwise edit with the same mtime would be possible. Strictly speaking there might be file system with a minimal mtime increment longer than one second. However it is unlikely that we will run the test on them for now. We can be smarter about this in the future if it becomes necessary. Differential Revision: https://phab.mercurial-scm.org/D11779