We could get into a race condition in `testAddFile` where the `DidChangeWatchedFilesNotification` would get handled after we try getting completion results that rely on it.
In a real-world use case, this is OK. Completion might still be incorrect until `DidChangeWatchedFilesNotification` gets handled but it will catch up eventually - usually earlier than later because in real-world scenarios the `DidChangeWatchedFilesNotification` and completion request are more than a few milliseconds apart.
In test, however, we need to guarantee deterministic ordering. Introduce a `BarrierRequest` that has `TaskMetadata.globalConfigurationChange` and thus ensures that all notifications and requests before it have finished before returning. We can run this fake request after sending the `DidChangeWatchedFilesNotification` to make sure that it is handled.
An alternative would be to mark `DidChangeWatchedFilesNotification` as `TaskMetadata.globalConfigurationChange`. But I would really like to avoid introducing a global ordering barrier between requests for a notification that is, for example, sent whenever a `.swift` file in the `.build` directory changes (e.g. on every package update).
996df8c597