refactor(lsp): resolve the config-client entanglement

Previously the LSP-Client object contained some fields that are also
in the client config, but for a lot of other fields, the config was used
directly making the two objects vaguely entangled with either not having
a clear role.

Now the config object is treated purely as config (read-only) from the
client, and any fields the client needs from the config are now copied
in as additional fields.

This means:
- the config object is no longet normalised and is left as the user
  provided it.
- the client only reads the config on creation of the client and all
  other implementations now read the clients version of the fields.

In addition, internal support for multiple callbacks has been added to
the client so the client tracking logic (done in lua.lsp) can be done
more robustly instead of wrapping the user callbacks which may error.

1 files changed, 2 insertions, 2 deletions

diff --git a/runtime/lua/vim/lsp/handlers.lua b/runtime/lua/vim/lsp/handlers.lua
index 4bb14e5a09..a9da812231 100644
--- a/runtime/lua/vim/lsp/handlers.lua
+++ b/runtime/lua/vim/lsp/handlers.lua
@@ -197,10 +197,10 @@ M[ms.workspace_configuration] = function(_, result, ctx)
   local response = {}
   for _, item in ipairs(result.items) do
     if item.section then
-      local value = lookup_section(client.config.settings, item.section)
+      local value = lookup_section(client.settings, item.section)
       -- For empty sections with no explicit '' key, return settings as is
       if value == nil and item.section == '' then
-        value = client.config.settings
+        value = client.settings
       end
       if value == nil then
         value = vim.NIL