feat: Implement diagnostics pull model

[Veykril]

Fixes #18375

[Veykril]

Okay implementing this is rather straight forward actually, that's nice

[rchl]

I know this should be a separate issue but for now I don't have time for that so just gonna point at sublimelsp/LSP#2572

Basically, there appears to be some issues with the implementation - the server still pushes diagnostics even if client supports pull diagnostics and also it returns empty diagnostics for pull request.

[Veykril]

Basically, there appears to be some issues with the implementation - the server still pushes diagnostics even if client supports pull diagnostics

This is intentional, the native rust-analyzer diagnostics support the push model, but the on save document handler that invokes cargo check remains using the push model as pulling makes little sense in that way (cargo is inherently pushing). The LSP does not forbid (to my knowledge) both to be used.

[jwortmann]

According to the comments in microsoft/language-server-protocol#1743 (comment) servers should not use both pull and push diagnostics at the same time (at least for a particular DocumentUri; what you are allowed to do is to register pull diagnostics only for certain URIs and then use push diagnostics for different URIs):

If a server opts into providing pull then the client pulls for diagnostics and the server doesn't need to push.

So I opt to simply add to the spec that a server if opting into pull it shouldn't push diagnostics for the same set of resources.

(though I think it was forgotten to add this last sentence to the specs explicitly)

---

Furthermore, since you don't seem to register an identifier for the pull diagnostics (as far as I can tell from the recording provided in sublimelsp/LSP#2572), and push diagnostics per definition don't have any identifier, it would mean that they just override each other for the same URI, i.e. the latest arrived wins.