Add support for lifecycleManagedByParent.

[tsmaeder]

What it does

Adds support for the lifecycleSupportedByParent flag on debug session. Fixes #11511

How to test

• Install built-in javascript debugger plugin with version 1.60.1 (https://open-vsx.org/api/ms-vscode/js-debug/1.61.0/file/ms-vscode.js-debug-1.61.0.vsix).
• Experiment with auto-attached debug sessions: I used Theia itself for testing: it includes both process with many subprocesses and also the launch.json in the repo contains composite launch configurations
• Make sure terminating debug sessions (root sessions as well as descendant sessions) shows the correct behavior as described in https://code.visualstudio.com/docs/editor/debugging#_compound-launch-configurations and https://code.visualstudio.com/api/references/vscode-api#DebugSessionOptions

Contributed on behalf of ST Microelectronics

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[msujew]

I noticed some issue related to parent and compound session management: When terminating a child session which has lifecycleManagedByParent, the corresponding parent session is correctly terminated. However, when the parent session is part of a compound session, only the parent session is terminated, not the whole compound. The following screencap demonstrates this effect:

2022-10-13.14-56-48.mp4

VSCode correctly terminates the whole compound session in that case.

[tsmaeder]

@msujew could you have another look, please?

[msujew]

@tsmaeder I haven't tried reproducing it, but looking at the code, I believe you didn't address the comment I had in here yet?

[tsmaeder]

I verified that the code correctly walks upward to the compound configuration an that it terminates all root sessions from there. I was able to reproduce the case where terminating the back end by hand would leave child sessions behind, but not reliably. Looks to me like it's some kind of timing issue that IMO is unrelated to the change at hand.

[tsmaeder]

Hmh....turns out the "currentSession" management in the UI is completely off: the session being terminated is not what's selected in the UI. Debugging.

[tsmaeder]

Some more debugging shows that the "Launch Browser Frontend" sessions has a child session which has lifecycleManagedByParent=false. So going stop going up the chain at this point, which explains why the back end is not completely stopped (just the part that is bound to the front end). Not sure why the session structure in VS Code looks so much different though.

[tsmaeder]

@msujew from debugging, I believe our behaviour is correct. Not sure why VS Code behaves differently, but one thing to keep in mind is that it is using a newer version of js-debug than what we are using.

[tsmaeder]

I debugged through this case in VS Code: debugCommands.ts#stopHandler() has code that walks from the selected debug sessions up the parentSession chain to the root: so what is being terminated is the Launch Browser Frontend session, not the editorWorker sessions. All this leads me to conclude that the code in this PR is correct. Whether we want to change our behaviour to match VS Code as far as which session to terminate when the user presses the "Stop"-button is a question outside the scope of this PR (but I would argue that our behaviour is the better one).

[msujew]

Alright, thank you @tsmaeder for investigating this, I'll now gladly approve this PR :)

I can confirm that the changes work as expected and the property is marked as supported in the API comparison report.