Improve solution load performance

[DustinCampbell]

Razor's language server does a lot of extra work to initialize that is really no longer necessary, at least in Visual Studio. This pull request is an attempt to remove a bunch of that extra work.

• In Visual Studio, no longer initialize the misc files project with _all- of the *.razor and *.cshtml files in the workspace root path. With the IRazorProjectInfoDriver in place, I believe this to be unnecessary work. Note that I've left this behavior for VS Code for now, but we might remove it later.
• If we do initialize the misc files project with all Razor files, add a method to IRazorProjectServer to add all of the documents to the ProjectSnapshotManager at once. Adding them one at a time results in a ton of extra asynchrony that slows solution load down as each document add hops around the thread pool.
• When IRazorProjectService.OpenDocumentAsync(...) is called, it first attempts to add the open document to the misc files project. This is because we might learn of an open document before the project system is done loading. However, it first adds the document using a TextLoader that loads the file off disk. Then, it updates the document with the SourceText that was passed to OpenDocumentAsync. However, this causes the file to be loaded so that its contents can be compared with the new SourceText. To avoid this additional I/O, OpenDocumentAsync will now add the document to the misc files project with the SourceText rather than a TextLoader.
• Don't create DocumentSnapshot instances unnecessarily when checking to see if a project contains a document file path.

In addition, I've refactored all of the IFileChangeDetector and IRazorFileChangeListener abstractions into the singleton, WorkspaceRootPathWatcher. There was only a single implementation of each, so they really don't have a lot of value. I've similar unified a bunch of relevant tests.

CI Build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2656343&view=results
VS Test Insertion: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/616458

[davidwengier]

I'd be fine with the removal of the feature flag, and just never adding every file to the project manager, but I understand if you prefer to be cautious.

I think the string check is wrong though.

[davidwengier]

To expand on my above comment a bit: in VS Code we sent textDocument/open for every file, regardless of whether it's open, so things would end up in misc files anyway I think.

[ryzngard]

Note that I've left this behavior for VS Code for now, but we might remove it later.

I think we absolutely should do this. From my understanding have them in the misc project provides some functionality but not anything needed if it's not open (I'm still reading the PR). Definitely can be a separate PR but this would also help alleviate some of the delay in startup that @dibarbet has been looking at for vs code.

[DustinCampbell]

Note that I've left this behavior for VS Code for now, but we might remove it later.

I think we absolutely should do this. From my understanding have them in the misc project provides some functionality but not anything needed if it's not open (I'm still reading the PR). Definitely can be a separate PR but this would also help alleviate some of the delay in startup that @dibarbet has been looking at for vs code.

I'd be delighted for somebody else to set the flag to test this out in VS Code. 😄

To expand on my above comment a bit: in VS Code we sent textDocument/open for every file, regardless of whether it's open, so things would end up in misc files anyway I think.

Why would we load every file from disk to send a textDocument/open for each? If I'm understanding the impact correctly, that seems to me like a clear performance problem.

[ryzngard]

Love it. Been on my backlog for a bit and glad you got to it first :)

[ryzngard]

Why would we load every file from disk to send a textDocument/open for each? If I'm understanding the impact correctly, that seems to me like a clear performance problem.

This is no longer true as of dotnet/vscode-csharp#7826

[davidwengier]

If I'm understanding the impact correctly, that seems to me like a clear performance problem.

Needs must. It was the only way to get rzls to start generating code, to send to Roslyn, so that references to Razor components were valid.

I guess I'm forgetting how we ended up getting that to happen. @ryzngard can you remind me? Is it just a side-effect of the named pipe, and our normal background document generator kicks in?

[ryzngard]

Is it just a side-effect of the named pipe, and our normal background document generator kicks in?

If we're doing it at all it would be because of the background document generator. Let's get an issue filed on VS Code to make sure we include this fix there. I don't think we do the add anymore... if anything it would go through the dynamic file updates. That would also make this change safe on VS Code but it's worth testing