Implement workspace/didChangeConfiguration and workspace/configuration

[katafrakt]

Motivation

Closes #3785

workspace/didChangeConfiguration and workspace/configuration are part of the spec. They are used to dynamically change the configuration of the server after initialization. With eglot, they are used to provide per-project configuration via .dir-locals.el files (see: https://www.gnu.org/software/emacs/manual/html_node/eglot/Project_002dspecific-configuration.html).

Implementation

This adds support for the pull model of dynamic configuration changes, as described here: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_configuration

Upon receiving workspace/didChangeConfiguration message the Ruby LSP server sends workspace/configuration to the client. The client replies. This reply is different than other replies handled by Ruby LSP so far, as it does not include method and needs to be associated with the request via id. This required implementing a collection of server-sent requests, to be able to match.

The result of the reply is not a hash, instead it's an array of hashes, so it needed to be handled separately as well.

Technically, upon receiving workspace/configuration the server should check if it should register or unregister some capabilities. I intended to do that too, but it started to become messy and also I did not have a way to properly test it, as eglot does not support dynamic registration of capabilities.

Automated Tests

TBH it's a bit short on tests. I wasn't sure where/how to add more. I welcome all the suggestions in that area, because it feels a bit undertested.

Manual Tests

I was able to swap the formatter and linter from Rubocop to StandardRB in eglot using this .dir-locals.el:

 ((nil
   . ((eglot-workspace-configuration
       . (:rubyLsp
          (:formatter "standard" :linters ["standard"]
           :enabledFeatures (:codeActions t :diagnostics t :formatting t)))))))

[graphite-app]

How to use the Graphite Merge Queue

Add the label graphite-merge to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

[katafrakt]

This is a hack to reuse apply_options, which expects initializationOptions, but perhaps should be properly extracted to a method just accepting the options to apply.

Also, this just takes first hash from the reply's result, which works here, because we only asked for one configuration item, but technically is not exactly in line with the spec.

[vinistock]

Yeah, this method is coupling information that we get during initialization (like the workspace folder) with other settings. It would indeed be nice to split into two methods:

1. One that handles information required by the spec (workspace folders, capabilities and so on)
2. Another that handles only the Ruby LSP's specific settings (what gets passed as initializationOptions)

Beyond just improving the design, invoking this twice may have weird consequences, like accidentally changing the negotiated encoding, so I don't think we can reuse it as is.

For example, if the editor and server negotiated UTF-8 initially, invoking this method without passing the capabilities -> general -> positionEncodings data will result in the server choosing UTF-16 (respecting the spec's default encoding), which would mean that editor and server would be trying to communicate using different encodings - leading to crashes, documents being in an invalid state and so on.

[vinistock]

My understanding based on the spec is that the parameters of workspace/didChangeConfiguration already include which settings are supposed to be changed.

Why do we need to make a request to the client? Could we use what we receive as parameters instead?

[vinistock]

We already process one response for server->client requests here.

Are we able to reuse that and avoid changing the base server?

[vinistock]

Yeah, this method is coupling information that we get during initialization (like the workspace folder) with other settings. It would indeed be nice to split into two methods:

1. One that handles information required by the spec (workspace folders, capabilities and so on)
2. Another that handles only the Ruby LSP's specific settings (what gets passed as initializationOptions)

Beyond just improving the design, invoking this twice may have weird consequences, like accidentally changing the negotiated encoding, so I don't think we can reuse it as is.

For example, if the editor and server negotiated UTF-8 initially, invoking this method without passing the capabilities -> general -> positionEncodings data will result in the server choosing UTF-16 (respecting the spec's default encoding), which would mean that editor and server would be trying to communicate using different encodings - leading to crashes, documents being in an invalid state and so on.