Remove onInitialConfiguration from InitializeCallbacks

[alanz]

The Initialize request does not include the initial configuration, so
parsing it to generate a configuration does not make sense.

If necessary, the server can request config on startup, if it is not
supplied, using ‘workspace/configuration’.

Closes #210

[alanz]

Note the discussion of config in the InitializeRequest, summarized here as

I will clarify the spec in a way that the initializationOptions is typically something that could be passed on the command line when starting the server. It shouldn't be user configurations.

I am actually against whitelisting workspace/configuration. If a server needs the configuration to register providers it should use dynamic registration instead of static registration which allows to mix workspace/configuration with registration calls.

[lukel97]

The Initialize request does not include the initial configuration, so parsing it to generate a configuration does not make sense.

Is this that lsp-haskell doesn't include the configuration in the initializeRequest?

[alanz]

@bubba I just looked, and lsp-haskell puts junk in there, which we are now reporting as a problem.

I am actually in two minds about this, on the one hand I will fix lsp-haskell, on the other we should encourage "good" use of the API.

And since it should include things like CLI options passed in, we should perhaps keep the parser, but change its return type.

[alanz]

Other options discussed on IRC

• make the handler a Maybe type, if it is set there should be a correct config, and report errors parsing it as expected. If the initializationOptions are used as the spec discussion suggests, for CLI or other server setups, they can be parsed in the server initializeRequestHandler.
• Make LanguageContextData take a second type parameter, for initializationOptions, which appear in their own field. Then if they refer to the same type, assume it is the config, and update both fields when it is parsed.
• Strip it out as per this PR, and let the initializeRequestHandler deal with it.

Of these, I think I prefer the first one.

Also, we currently have the initializeRequestHandler set via the handlers, and the onStartup field of InitializeCallbacks. Perhaps we could merge those, by providing the request message to onStartup as well. We only ever expect to receive this message once per server lifetime.

[lukel97]

@alanz sorry for the late reply. Option 1 sounds good to me too. Does this PR need to be merged then for it?

[lukel97]

Superseeded by #244