fsmonitor: write state with wlock held and dirstate unchanged (issue5581) This means that the state will not be written if: (1) either the wlock can't be obtained (2) something else came along and changed the dirstate while we were in the middle of a status run.

workingctx: add a way for extensions to run code at status fixup time Some extensions like fsmonitor need to run code after dirstate.status is called, but while the wlock is held. The extensions could grab the wlock again, but that has its own peculiar race issues. For example, fsmonitor would not like its state to be written out if the dirstate has changed underneath (see issue5581 for what can go wrong in that sort of case). To protect against these sorts of issues, allow extensions to declare that they would like to run some code to run at fixup time. fsmonitor will switch to using this in the next patch in the series.

workingctx: also pass status tuple into poststatusfixup fsmonitor is going to need this to compute its set of notable files to persist.

workingctx: factor out post-status dirstate fixup We want to allow extensions to be able to add code to run inside the wlock.

merge with stable

profile: properly propagate exception from the sub-context manager Context manager has a mechanism to control extension propagation. It is not used by profiling right now, but making the code correct will help prevent bug in the future.

profile: close 'fp' in all cases There are no way for this to happen today, but better be safe than sorry, no one know how the code will evolve. We now make sure the file pointer is closed even is profiler is None.