largefiles: use `hacky_extension_update_file` in `openlfdirstate` This is what the function is meant for.

win32text: make the hacky call cover more cases Now that I understand what this is doing, It seems like the case for `p1_tracked` were covered by neither the code nor the test. Now the code cover it at least.

win32text: drop the `changing_parents` context in revert upgrade We are not changing parents here, so let us not pretend we do.

win32text: clean up and clarify the post-revert hack of dirstate The change is unrelated to changing parents and should not be a in a "changing_parents" context. This call is quite hacky, but now it is at least explicitly hacky. We will drop the `changing_parents` context in the next changesets, but we kept this change simple to help readability.

dirstate: introduce a `hacky_extension_update_file` method See inline documentation for details.

mq: properly take the wlock during the full qfold operation Otherwise the operation could be raced… for unknown result.

locking: hold the wlock for the full duration of the "keyword demo" The risk of racing the demo is low, since it seems to create its own repository on the fly. However it is clearer and more consistent.

locking: grab the wlock before touching the dirstate in `perfdirstatewrite` If we touch the dirstate, we should hold the `wlock`.

locking: take the `wlock` for the full `hg addremove` duration Otherwise, there is a race condition window between the time we resolve the file to addremove with the matcher and the time we lock the repo and modify the dirstate. For example, the working copy might have been updated away, or purged, and the matched files would no longer be correct.

locking: take the `wlock` for the full `hg forget` duration Otherwise, there is a race condition window between the time we resolve the file to forget with the matcher and the time we lock the repo and modify the dirstate. For example, the working copy might have been updated away, or purged, and the matched files would no longer be correct.