feat. Support ServiceHostClient light version

[albertli-msft]

support_light_serverhost_client_Code_Z8w0nkhleI.mp4

Support a light version ServiceHostClient that allow TaskRunner and Debuger reusing it to connect the host.

• I. Move socket connection logics into a reusable socket client and create bunch of promise helpers.
• II. Break a light version ServiceHostClient out of original ServiceHostClient
• III. Create a new PqSdkTaskTerminal, taking ServiceHostClientLight, as the task runner when it connects the servicehost
• IV. Enhance existing MQueryDebugSession to take ServiceHostClientLight while the extension using the servicehost

[mattmasson]

A more standard term seems to be CancellationToken, but I don't feel strongly about this.

Are there existing cancellation interfaces in the vscode APIs? Would it make sense to use them here?

[albertli-msft]

rename CancelToken into CancellationToken;
rename CancelSource into CancellationTokenSource;
and also implement vsc's CancellationToken for future integration.

I was thinking, we gonna have to adapt nodejs abort onAbort signal, or even other cancellation token from its source, like vsc cancellation tokens.
Thus, I was thinking it would be safer to have our own cancellation implementation as a buffer layer where we could combine or adapt to any when we needed. 😬

[mattmasson]

Could you explain what this is doing?

[albertli-msft]

Yes, the symbol can guarantee there would be only one single reference of the symbol value at the runtime.
And we could use the symbol as the index key to return a cancelTokenTag string, that tag string could be used to tell us whether one cancellation token instance is one of us customized cancel token instance or not.
By using the symbol key, we would avoid naming collision, there won't any risks of other types of cancellation tokens carrying similar tags and confused us. 😬