make caching more robust; fixes #69534

[weinand]

This PR fixes #69534.

When talking to the EH I was sending the debug session data only once in the first request that needed it. Then EH cached the data.

For subsequent request I'm sending only the session ID (and the EH looks up the session object from the cache). VS Code made the decision whether to send the full data or just the ID base on a "Set" data structure: after sending the data once, the ID is added to the Set.

After "workspaceService.resolveWorkspaceFolder()" had become asynchronous, the timing behavior has changed and now the EH cache does not have the data when a session ID arrives and needs to be looked up. This results in a "null" session and the error message on the console.

The fix is to introduce a robust (but still synchronous) caching protocol. For this the EH sends a new request "sessionCached" back to VS Code when it has cached the data. And VS Code only stops sending the full data if it has received the "sessionCached" request.

[isidorn]

Thanks for the explanation and the PR. I will review in more detail in two hours.

[isidorn]

This PR looks good overall.

I have some questions:

• Did we verify this fixes the issue?
• Why did we originaly decide to sometimes send over the ID? Why don't we always send over the session (in that case this caching logic would not be needed)? In case we decide this makes sense we should do it in master, not for the fix.

However since we do not plan to merge this PR over the weekend we can discuss these things on monday morning in the office.

[weinand]

@isidorn The fix is already in Insiders and Dan has verified with his own build that it fixes the issue.

We decided to send only the ID when we started to always send the launch config with the session which makes the amount of data passed with every event and every request quite large.

[isidorn]

LGTM

[isidorn]

@weinand just a ping / reminder to merge this in.