status: invalidate dirstate on LockError If we cannot take the lock, someone else is modifying the repository. Let us discard dirstate uncommitted data before exiting the status code. Having a clean dirstate after such operation seems safer. Strictly speaking, there is a small behavior change in the following situation: * process A call `status` outside of the `wlock` * process B grab the `wlock` * process A fails to acquires the lock to write status fixup * process B release the `wlock` *without touching the dirstate* * process A later grab the `wlock` * process A can write dirstate update from earlier `status` However this is a fairly hypothetical situation : * process A has to be raced * process B have to not update the dirstate * process A has to run another *unrelated* operation later. This seems rare enough to overlook. I am stating that the two operations in process A has to be unrelated. Otherwise, collecting status data outside of the lock to use them inside the lock is racy. Any other process could move things around (eg: the working copy) making the data collected during status irrelevantor even harmful. If such code exists, it should be fixed ASAP.

status: simplify the post status fixup phases With the wlock automatically discarding changes when applicable, we can simplify the code a bit. * we perform the fixup operation before trying to grab the lock to narrow the `try/except` * we no longer need to explicitly complare dirstate identities. We can trust the dirstate internal refresh for that. It would invalidate dirty data when needed. * detect still data invalidation by checking the dirty flag before and after taking the lock. Doing this is actually only necessary to issue the debug message, we could blindy trust the dirstate internal to ignore the `write` call on a non-dirty dirstate.

dirstate: cleanup the `_map` property cache The removed code was duplicating the effect of `@propertycache`. This is a gratuitous cleanup.

dirstate: only reload the dirstate when it may have changed This reinstall the equivalent of what the `filecache` was doing. However it does it at the dirstate level. There is a double motivation for this: - This avoid duplicating logic with the dirstate "identity" logic. - This increase the lifetime of the `dirstate` object, helping to implement change scoping.

dirstate: directly manage the dirstate property on localrepo Before we had: * the filecache layer on `localrepo` doing some caching * the dirstate having some internal invalidation/refresh machanism * the status code doing some identity validation. To clean this up, we are dropping the first item "localrepo `filecache`" from the equation in a favor of an approach integrated into the dirstate (second item) in the next changesets. This changeset will be a small windows where some things will be a bit slower. This will be fixed in the next changesets.

dirstate: factor the identity getting/setting code in the dirstate map We are doing the same things twice and we will add more logic in the next changesets. So lets start factoring things out now.

dirstate: use `cachestat` object for dirstatemap identity There is a class dedicated to this kind of cache check, let us use it. We will generalize this code in the next changesets, but we do the "behavior changing" pass on our own.

automv: lock the repository before searching for renames I detected this while debugging something else.

dirstate: distinct transaction callback from largefile This has not caused any issue so far because the large-files dirstate bypass the transaction logic. We might want to change that. In anyway, let us disarm this bug nest before it actually explode.

dirstate: track that changes are pending in a transaction Nothing is currently broken because if this, but this make the `_invalidated_context` attribute more accurate. Being more accurate here will help us later, when dealing with `status` call.