Support `initializationOptions` to configure the server

[tkrabel-db]

What changes are proposed in this pull request?

Fixes #195.

The language server supports passing initializationOptions with the initialize message, but actually doesn't do anything with it. I think this was an oversight. This PR supports overriding configuration settings using the initializationOptions field.

How is this tested?

• Added a unit test
• Manually

[krassowski]

Some context:

• as per spec initialization options are different from configuration options; however there is no agreement as to how they are different; there was an attempt to standardize it in https://github.com/microsoft/language-server-protocol/commit/545cd6958ace603cd254e8e376e4fb2840bb1223 but after discussion in lsp#567 it was reverted due to lack of consensus
• this was previously discussed in https://github.com/python-lsp/python-lsp-server/issues/195 so it is not an omission - we should follow the discussion in there
• one way that these two could be use used differently, and are used differently by some language server is following https://github.com/microsoft/language-server-protocol/commit/545cd6958ace603cd254e8e376e4fb2840bb1223: initialization options could include pythonVersion: string which is required during initialization but configuration options would have showWarnings: boolean which can be adjusted on runtime

[tkrabel-db]

@krassowski thanks for the context.

I have a clear use case in mind: enabling rope_autoimport without a config file. From the code and https://github.com/python-lsp/python-lsp-server/issues/195 I see that workspace/didChangeConfiguration is the supported way to achieve that, and I am happy to go with that approach.

I feel the discussion around initializationOptions is unfortunate. There is no consensus around how initializationOptionsshould be used, but many developers find it very useful to configure the server on initialize. I think so too.

As more and more language servers will run in cloud VMs and not on a local machine, these servers need to be configurable dynamically. workspace/configure is a valid general approach to handle server configuration at runtime, but using that to enable/disable some features is overkill, wasteful and will lead to bad user behaviour.

• It's wasteful because you will end up turning off features that might have been enabled already on initialize, consuming resources unnecessarily (think e.g. rope_autoimport, which needs to index python modules; that problem becomes worse when the language server lives in an ephemeral environment like a cloud VM)
• It will lead to bad user behaviour since the client will already send messages and potentially receive responses from features that the used didn't even want to use in the first place (e.g. getting ruff diagnostics instead of flake8 ones).
• It is overkill because it will require extra logic to make sure the server is responsive while requesting workspace/configuration and while applying it (something that would be a no-brainer with initializeOptions as the server hasn't send a response to that yet, so the client keeps waiting)

[tkrabel-db]

Anyway, I moved my comment to #195, i.e. here

[tkrabel-db]

@ccordoba12 thanks for supporting this feature! I addressed you comment and also refactored the unit test to use the new test util functions