Compile errors are reported after they have been fixed

[odisseus]

Steps to reproduce

1. Start Fury as a Nailgun daemon.
2. Compile fury/frontend
3. Introduce a compilation error in one of the modules on which fury/frontend depends, e. g. fury/compile.
4. Recompile fury/frontend. Observe the incomplete graph and a build diagnostic message (or multiple messages)
5. Restore the incorrect code to the state exactly as before the error was introduced.
6. Recompile fury/frontend. Observe the complete graph and zero exit code despite the diagnostic messages.

Notes

• The spurious diagnostic messages don't appear if the fixed code has differences (e. g. in variable names) from the original code.
• The spurious notification build/publishDiagnostics, which signals compilation errors, contains the lines of code as they appeared before the error has been fixed.
  • However, this is not the same notification that might have been cached anywhere inside Fury; it is a new notification sent by the build server, which contains outdated information.
  • This doesn't prevent the server to compile the corrected code successfully.
• This also happens in the watch mode, as automatic recompilation is triggered.
• This issue is one of possibly multiple causes that constitute #883.

[odisseus]

The problem is also present when Fury commands are run in the standalone mode. This means that the problem lies either within Bloop, or in the way Fury communicates with Bloop.

[odisseus]

The problem does not appear if Bloop is killed after step 4 (that is, after the failed compilation).

[odisseus]

The commit https://github.com/scalacenter/bloop/commit/92c23aefdaf2602a6ffeb357518ef4a6db445d0f might be related.

[odisseus]

This issue is much less visible after PR #949 has changed the way BSP connections are managed, but the root cause (in my opinion, that's the strange behaviour of Bloop) is still present, and the issue should still appear in standalone mode.

[propensive]

I'm going to defer this to a later milestone.