dotnet
Re-enable CodeFolding Integration tests
We'll be disabling the CodeFolding integration tests because they are flaky, but we should make turning them back on a high priority because the REASON that they are flaky is quite spooky.
@davidwengier and I investigated and it seems that on startup for a given HostDocumentVersion (version of Razor file) there are multiple versions of the C# generated file (assumedly it's incrementally creating the document). The result of this is that the initial (as soon as the first Razor document is opened) FoldingRange request may be run against an empty or incomplete C# document, resulting in no C# folding results. This state will persist because the client won't ask for Ranges again until there is an edit made, at which point the C# document will be fully generated.
This has very spooky implications for over-all document serialization, I think it's just expressing itself in CodeFolding because it's run very early in the document lifecycle and doesn't have "recovery mechanics" as part of the feature (like "refresh" does for semantic tokens).
A random idea: For open documents, it should, in theory, be possible for us to "just" forward didOpen, didChange and didClose requests that we get for Razor files, and send Roslyn those same notifications for the generated files. This would mean that Roslyn's server will synchronize requests on the latest versions etc.
For closed documents we'd still need to update things so other features work, so we still would want to track down this issue, but it might simplify things for open documents.
