File sync from disk can become parallel with any operation that shows a dialog

[peterflynn]

I haven't tried to find a specific case where this breaks very badly, but I have no doubt they exist.

Showing the basic problem, albeit only as a UI glitch, is easy though:

1. Make some edits
2. File > Close -- but leave the unsaved changes prompt open
3. Leave Brackets and modify the same file on disk (do save your changes here)
4. Return to Brackets

Result: the "External Changes" dialog appears on top of the unsaved changes prompt.
(Warning: be sure to dismiss the External Changes now. If you don't, and you leave the Brackets window with it still open, you'll hit #554 and be stuck force-quitting Brackets).

So now all the FileSyncManager operations are happening in the middle of what DocumentCommandHandlers.handleFileClose() probably thinks of as an atomic operation. This can happen with anything that might open a dialog in mid-operation -- the operation can unexpectedly become interleaved with FileSyncManager, as if we were multi-threaded. (Similarly, any operation that is triggered by something other than user input could take the place of FileSyncManager).

In a way, this is just another case of the general issue where sequenced operations that should feel atomic are not actually guaranteed to be so. It's just that most of those issues don't repro without truly async file I/O, whereas this case of it already repros in our code today.

[njx]

QRB reviewed. Marking to user story--originally we were going to wait to handle these async issues until we started dealing with async file access (e.g. to github or dropbox), but this suggests that we should consider handling at least some of these issues earlier in a separate user story.

[pthiess]

Added to BS --> story #306240