Unbundle LSP.Sever

[michaelpj]

At the moment LSP.Sever is "framework-like": you provide various kinds of functions via the monolithic SeverDefinition, and then the server framework is responsible for calling them. This has some warts:

• It is unclear what is handled by the framework and what isn't (see e.g. Changing the configuration after workspace/didChangeConfiguration requests #414)
• It is difficult to customize parts of the behaviour
  • A big example is the message dispatch loop. Our "reactor" example is (IMO) godawful: you have to override the handlers in order to sneak in some custom dispatch logic. ghcide similarly tries to completely bypass this. (Also see e.g. Concurrent handling of lsp handlers #409)
  • Another example is whether or not to feed the intializationOptions to the configuration changed function. This isn't specified in the spec, but some clients expect it, so it's really something the server author should decide about, not us.
• It is difficult to mange state differently. For example, HLS wants to delay updates to the VFS so that long-running processes don't see inconsistent states. To do this they have to implement a complete second layer which takes VFS snapshots!

Here's some ideas for how to unbundle this:

• Modularise the server in/out into IO actions that communicate over a channel, which clients can fork as they like.
• Modularise the initialization handlers so we provide a number of standard handlers which do common actions and which can be combined with <>.
• Modularise state accesses so that they access the state via a typeclass, allowing multiple implementations.
• More?

Big questions:

• Is this a good direction of travel?
• Are there going to be any bits that will be really difficult?

[michaelpj]

@wz1000 thoughts?