Respect client capabilities when choosing codeActionProvider return type

[tgjones]

Possible fix for #136, but I'm new to this project so I've quite possibly misunderstood what needs to be done.

[bjorkstromm]

@tgjones thanks for your PR... Some time ago, I went trying to fix this issue in another way (the null serialization), see #140.

However, this includes checks for respecting client request, which is a good thing. I "think" we should create a factory method in ServerCapabilities for constructing it, as mentioned in comments:

csharp-language-server-protocol/src/Protocol/Server/Capabilities/ServerCapabilities.cs

Lines 13 to 15 in 62cda45

	// TODO NEXT:
	// Create ability for server capabilties to be pulled from registered handlers
	// Create the ability to look at the client capabilities to determine what parts we need to answer now (completion for example)

[david-driscoll]

Going to close this for the moment, as the fix doesn't seem appropriate, but I'll give some context (because the code isn't well documented on this!)

GetStaticOptions does a check for IsSupported. It also does a check to make sure that there is an object value that came from the client (the editor). And it checks for DynamicRegistration . VsCode does something really interesting here when you deal with Dynamic Registration.

If we report that we support code lens at this point, vscode will statically bind code lens to whatever selectors were provided with the extension. We then process any handlers that support dynamic registration and after initialization we issue all the registration requests. This then causes a double registration to happen. So we actually get bound to code lens once for the provided selectors (with the extension) as well as any extensions that we provided through dynamic registration. This is why the server will in some cases report that it doesn't support something, because we will after the fact bind dynamically to the client.