Adding LSP client completion for Razor handler and removing legacy completion

[alexgav]

Adding LSP client completion handler and removing legacy completion

Implementation notes:

1. Most of the code is a combination of what VS client does for razor/completion and razor/completionResolve requests https://github.com/dotnet/razor/blob/main/src/Razor/src/Microsoft.VisualStudio.LanguageServices.Razor/LanguageClient/Endpoints/RazorCustomMessageTarget_Completion.cs and what old code did in https://github.com/dotnet/vscode-csharp/blob/88bbc90365504031abf62eccde21b402211facce/src/razor/src/completion/razorCompletionItemProvider.ts#L27C14-L27C41 and https://github.com/dotnet/vscode-csharp/blob/88bbc90365504031abf62eccde21b402211facce/src/razor/src/completion/provisionalCompletionOrchestrator.ts#L17C14-L17C47
2. In a nutshell,
   a. for C# (in non-provisional completion case) we call roslyn completion directly to get completion list.
   That will already be in LSP format and we can just return it.
   b. for HTML, we execute vscode command to get completions. Those will get returned in vscode format, so we need to translate them to LSP format before returning them to Razor server.
   c. for C# (in provisional case) we currently have to use vscode command as well instead of calling Roslyn directly. That's what existing code currently does and calling Roslyn directly via Roslyn command causes null to be returned. There is Provisional Completion in Razor should show full tooltip info #7250 filed to follow up on that.
3. We do have to "massage" to Roslyn LSP completion results a little before returning them to Razor server, mostly to copy default item data to each completion item. Otherwise completionResolve fails in Roslyn
4. Most of the provisional completion code in the deleted ProvisionalCompletionOrchestrator was
   a. Detecting that this is in fact a provisional completion case. We don't need that now since server tells us when it is the case by supplying non-null provisional edit.
   b. Detecting when the user is done interacting with completion so that provisional edit (temporarily added '.' in C# projected document) can be removed. We don't need to do that since we just get the data from Roslyn and return to the server. We can remove provisionally added '.' immediately after getting the data from Roslyn.

Main wins after this PR:

1. Legacy completion code in Razor server can be deleted.

2. Tag helpers are now added to HTML completion
   

3. Correct glyphs/icons are shown for HTML and provisional completion C#
   
   

[davidwengier]

Mostly looks good. Definitely on the right track.

[davidwengier]

I don't see the change to opt the server into the new completion system. Would need a command line argument added to where rzls is called. Without that, I'm not sure this endpoint would get hit.

[alexgav]

I don't see the change to opt the server into the new completion system. Would need a command line argument added to where rzls is called. Without that, I'm not sure this endpoint would get hit.

There is matching change in Razor repo here

    if (featureOptions.SingleServerCompletionSupport)

I haven't gotten that PR out yet. It basically removes the "if" check and the "else" clause. I am guessing there is more clean-up of unnecessary "Legacy" classes. I'll get that out shortly.

I confirmed that after that change the new endpoint in VSCode is getting hit and returned data processed. Is there something else needed?

[davidwengier]

I haven't gotten that PR out yet. It basically removes the "if" check and the "else" clause

Thats cool, but it means we need a dual insertion for things to work. The alternative is to pass --SingleServerCompletionSupport false to the language server (here) and then this can be merged and will work with whatever Razor bits happen to be inserted, and once this is merged we're free to independently remove the old functionality because nothing is using it. That is all dependent on their being no other changes to the server needed for this to work.

[alexgav]

--SingleServerCompletionSupport false

I'm guessing you meant true since false seems to do the opposite of what we want? Confirmed that true makes server-side code changes unnecessary (or not immediately necessary).

[davidwengier]

Tests would be wonderful...

[alexgav]

Tests would be wonderful...

Agreed, I'd prefer to add in a follow up PR though to make sure this gets in - unless you feel strongly otherwise. Starting to work on them.

[davidwengier]

Follow up is fine, not going to block.