Sometimes we add custom functionalities that are not specified in the standard LSP spec.
For example, for features like vulnerability check and gc details,
we expected the clients to apply heuristics to figure out what features are available.
For example, vscode-go extension used a mix of gopls version (either from gopls version or
go version -m command, or from the version encoded in InitializeResult.serverInfo.version field),
or existence of a certain command in ServerCapabilities.executeCommandProvider.commands list,
or optimistically assume new functionalities and handle failures. These sort-of worked when custom
commands are involved.

Now we are discussing a prompt ability for go telemetry and adding a setting to control it.
VS Code adds most of the gopls settings in the InitializeParams.initializationOptions, the very
first message sent to gopls. This can be problematic if the gopls is not able to recognize the setting
yet because the gopls is currently very strict about unrecognized settings.

Some options to consider:

1. Relax gopls's behavior around unknown settings. For diagnostics and visibility, we can still let gopls
   add unused settings.

2. Require clients to delay sending such configuration until they receive InitializeResult that
   provides hints about gopls's capabilities. Currently only the version info and commands list are used,
   but we can also extend the initializeResult to include dynamically settable custom gopls settings list.

3. Require clients to figure out the capability through a side channel (e.g. gopls version, gopls api-json, ...).
   This is the currently available option and I hope we can do better than that.