LSP client settings

[MichaReiser]

Similar to Ruff's LSP. Support setting some (or all) settings from within the LSP client. Allow setting LSP specific settings.

[dhruvmanila]

There's some additional context at #282 around using pull model for configuration instead of the current way which relies on initialization options.

[dhruvmanila]

Looking through astral-sh/ruff#18984, I went on a bit of a rabbit hole:

After reading a couple of issues / PRs mentioned in microsoft/language-server-protocol#567 (comment), it's a bit ambiguous on what the server needs to do exactly but here's what I've gathered so far:

• The InitializationOptions should only contain the options that are static while the server is active e.g., any command-line options because any change to these settings require a complete restart of the server
  • For us these would be the logLevel and logFile options for now because we cannot update the global tracing subscriber (ref)
• Initialize each workspace with the default options during initialize
  • Should we read the option values under the ty, python and any other namespaces from InitializationOptions ? I don't think we should as that would be fetched via the workspace/configuration request
  • This would mean that the user doesn't need to provide the server settings via the initialization_options (name might differ from editor to editor) and can directly provide via the generic settings mechanism for that editor
  • But, reading through https://rust-analyzer.github.io/book/configuration.html, it seems that some editor might not support workspace/configuration so the users are forced to specify them via InitializationOptions. Looking at the editors page, it seems to be Emacs via eglot, Vim via vim-lsp, Kate texte editor although I haven't confirmed whether it's still the same as of today (2025-07-02). So, we might still want to read the initialization options.
• The server should fetch the settings for a specific namespace (e.g., ty, python) for all the workspaces after initialized via the workspace/configuration request
  • The server can still process any requests / notifications while the server is waiting for the configuration response from the clients but we will opt into locking the server to defer processing these notifications or requests. This is what this PR is also doing.
• When the server receives the workspace/didChangeConfiguration notification, the server should refresh the settings from all the managed workspaces, ignoring any values in the notification payload.
• The server should update the internal cache of workspaces when it receives the workspace/didChangeWorkspaceFolders as:
  • For all the added workspace folders, update the internal state to include the new folder and fetch the settings for this folder
  • For all the removed workspace folders, remove any internal state related to this workspace

[dhruvmanila]

As per this conversation, we also need to explicitly register for the didChangeConfiguration notification. According to the spec:

This pull model replaces the old push model were the client signaled configuration change via an event. If the server still needs to react to configuration changes (since the server caches the result of workspace/configuration requests) the server should register for an empty configuration change using the following registration pattern:

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_configuration