Fixed a crash on completions with auto-imports racing with DidClose notification

[Andarist]

Root cause behind the crash:

• the completion request is split into 2 phases, a sync one and async one
• in the async one the completion request might be retried on ErrNeedsAutoImports
• but in between the first one and the second one a project change might come in (like DidClose or some other change)
• currently, the retried request flushes the pending changes (like DidClose) and resends the adjusted request
• that creates a mismatched code expectation because the closed file gets removed from the specifierCache and the request panics

There are 2 fixes in this PR:

• a request should always be served for the change.RequestedFile. That entry isn't removed from the specifierCache. It's not up to the server to cancel a pending request even if the state changed.
• a 2-phase request should use a consistent snapshot for the whole request to avoid its steps using different state and ultimately leading to confusing/erroneous results (although usually a small deviation there would usually be somewhat acceptable... I think it's still better to use a consistent state, and I think it's consistent with Acquire snapshots synchronously while blocking other requests/notifications #2765 ). For that reason, a snapshot gets acquired in the sync phase and reused by the async phase - achieving consistency.

Configuration	close before completion	close during async	unopened file	snapshot freezing (DidChange)
No fixes	CRASH (no response)	CRASH (nil deref panic)	PASS	FAIL (someVar missing)
Registry fix only	PASS	PASS	PASS	FAIL (someVar missing)
Snapshot freezing only	CRASH (no response)	PASS	PASS	PASS
Both fixes	PASS	PASS	PASS	PASS

fixes #2882

[andrewbranch]

I have a branch with this in it as well that I passed off to @gabritto as she was working on fixing a related crash. I think my branch wasn't quite right or was insufficient; I'm not sure what the status is. However, in mine, after we clone the snapshot for auto-imports, we check to see if the session can adopt the new one as the latest snapshot - I think we'll want that functionality.

[Andarist]

I couldn't really test this through fourslash so I had to resort to rolling a new test file that could use the NewLSPClient directly with a greater control over the performed actions.

[gabritto]

Couldn't we write a test using session directly? I did this recently in https://github.com/microsoft/typescript-go/blob/main/internal/project/snapshot_test.go#L125 to test things related to the timing of changes being processed.
We may need a better testing setup for those kinds of bugs long-term, but maybe right now using session for testing could do.

[Andarist]

I planned to add a test using the session directly later on. I just wanted to have more real-life test cases for this too and focused on those here.

[gabritto]

@Andarist Here's how I was doing the work of re-using the snapshot + extra information computed in an old PR:
https://github.com/microsoft/typescript-go/pull/1871/changes#diff-b8a62f01d8c9b6ed8df3c61e62fe4b694885da67eadb682a4117ce2cb62b1bf9R754-R784

But the tricky part would be to figure out whether to release the snapshot or not, I'll have to think about that.

[gabritto]

I think for the snapshot lifetime handling, we can (1) invoke snapshot.dispose() inside snapshot.Deref() when the count reaches 0, and (2) make sure both session and the server call .Ref() and .Deref() when they acquire/release it. So if you did the whole thing I linked above of enqueuing of a snapshot with auto-imports to see if session can adopt it, that would come with a call to .Ref()/.Deref(), etc.