VsChromium sometimes rescan files too many times in a row

[rpaquay]

This is related to issue #35.

VsChromium has 2 main components for synchronizing its index: one component keeps track of the file system structure (list of files and directories) and another keeps track of the contents of these files.

Both of these components run potentially long running file system operations on separate threads, serialized via a queue. This means there is a guarantee that file system scans never run concurrently (that would be sub-efficient as it would merely increase i/o latency). However, these long running tasks don't currently support cancellation, meaning that VsChromium can end up enqueuing tasks that will essentially perform a similar operation as the currently running one.

It would be more efficient to be able to cancel the currently running task when enqueuing a new task that will provide a similar (but more up to date) result.

Corner case scenario:

• Open a "vs-chromium-project.txt" file in VS
• A file system scan immediately starts (to discover files in that directory)
• Quickly close the "vs-chromium-project.txt" file
• The file system scan keeps going (because even though there is nothing to scan, the currently running task is not cancelled)

Ideally, the file system scan would be cancelled soon after the "vs-chromium-project.txt" file is closed.

Note that this is only visible for large projects, such as Chromium enlistments, that contains thousands of directories and files.

[rpaquay]

Note the same issue applies to the file contents loading components: its long running tasks should be cancellable.