do not invalidate the BackgroundCompiler config on DocumentChanged

[dhwed]

Completion is currently taking 5-10 seconds to show up in dotnet core SDK projects with many references.

After some investigation, it looks like the call to BackgroundCompiler.InvalidateConfiguration is tying up the reactor by creating a new IncrementalBuilder every time an open file is modified. It doesn't appear to me that this invalidation is required, but I may be missing something.

This change fixes the performance issue, and I haven't seen any issues during my testing.

@KevinRansom Did I miss a reason why this invalidation is required on the DocumentChanged event? If I am correct that it isn't necessary, can we also skip this invalidation anywhere else?

[msftclas]

All CLA requirements met.

[forki]

@vasily-kirichenko said he fixed exactly the same bug a year ago. But somehow the rewrite introduced it again

[cartermp]

Looks good code-wise and completion does feel faster for me. Thanks @dhwed!

[saul]

Is it worth @dsyme weighing in here about when invalidation is necessary? We can probably invalidate in fewer cases, too.

[dsyme]

Yes, that looks wrong

@saul When does DocumentReloaded get triggered?

@KevinRansom Do you know why we are doing anything at all for DocumentChanged? Was there a particular case that motivated this? e.g. why do we need to call UpdateDocumentInfoWithProjectId at all for OnDocumentChanged?

    member private this.OnDocumentChanged(projectId:ProjectId, documentId:DocumentId) = projectInfoManager.UpdateDocumentInfoWithProjectId(projectId, documentId, "OnDocumentChanged", invalidateConfig=false)