Make LSP client proxy support dynamicRegistration for client capabilities

[dkuleshov]

Actual implementation does not support dynamic client capabilities registration. In order to make the workflow more flexible we should support it. Seems like depending on the implementation some servers can provide capabilities dynamically (e.g. Golang server).

See WorkspaceClientCapabilities and TextDocumentClientCapabilities in LSP Specification.

[gorkem]

@dkuleshov Is this a blocker for Golang server? jdt.ls also supports dynamic capabilities however if a client does not support it the server should be able to fall-back to fixed capability reporting. If this is not the case for Golang we should report it.

[dkuleshov]

@gorkem According to what I see golang LS ignores dynamicRegistration set to false and tries to register a new capability. The bug is reported here #9796, we will report the golang LS bug if it is confirmed during the work on our bug.

I'm not yet sure if that's a blocker for #9781 but if it is than it will be mentioned here as well.

[vparfonov]

Will take to the nearest sprint for analyzing this ability for our client

[gorkem]

@vparfonov Do we really need this supported on the GWT IDE? LS implementations are supposed to work without it.

[vparfonov]

I think it's just nice to have, not critical. Firstly we need to upgrade lsp4j (#9864), and fix several technical impediments. Which mainly comes from our feature for supporting multi language server for on opened file.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.