x/tools/gopls: resend diagnostics for changed files

[findleyr]

In #50267, I added a (hidden) chattyDiagnostics option to gopls that publishes diagnostics on each change to a file, even if the diagnostics have not changed.

In practice, this doesn't seem to matter for VS Code has eliminated some cases where certain vim and emacs LSP clients get confused.

For example, from empirical observation coc.nvim seems to be subject to the following race. In pseudo-LSP (-> is client->server, <- is server->client):

1. -> didOpen(a.go)
2. <- publishDiagnostics(a.go, version 1, ["something bad"])
3. -> didChange(a.go) // fixes the diagnostic, creates version 2
4. <- publishDiagnostics(a.go, version 2, [])
5. -> didChange(a.go) // add whitespace, creates version 3
// gopls publishes nothing, because diagnostics didn't change

If the client observes (4) and (5) in the opposite order, it skips the diagnostics from 4 as they relate to a stale version. Then gopls never publishes another set of diagnostics (because it thinks the last published diagnostics are valid), and the client still shows "something bad".

Simply always publishing diagnostics after changes has fixed this problem, so we should make this the default behavior.

[findleyr]

I'll add:

• an additional diagnostics notification following file changes does not increase LSP traffic significantly; there is already a lot of chatter after changes (e.g. new requests for codeLens)
• our current behavior is probably incorrect according to the spec: "When a file changes it is the server’s responsibility to re-compute diagnostics and push them to the client." (spec)

[gopherbot]

Change https://go.dev/cl/429935 mentions this issue: gopls/internal/lsp/source: make "chatty" diagnostics the default