debug: refactor DebugService into DebugServer

[paul-marechal]

The DebugService interface is doing too many things: it is both implemented in the frontend (PluginDebugService) and in the backend (DebugServiceImpl). There should be a single DebugService that handles multiple debugging sources as contributions. The plugin-ext package should not rebind DebugService as it is currently done.

[tsmaeder]

If we start changing those interfaces (and we should), we should really make sure to get the community on board, in particular the folks at ARM, for example. They seem to use this stuff beyond VS Code extensions. @thegecko

[thegecko]

Indeed, the debug services can execute in both frontend and backend contexts.

If merging into a single service, it needs to:

• Be able to be loaded into frontend or backend on demand based on the debugger extension being loaded (loaded using extensionKind)
• Not rely on node libraries
• Work with the example browser debugger I created (see Support executing debug in the browser #10748 (comment)) or https://open-vsx.org/extension/arm/embedded-debug

[tsmaeder]

I've been reading through the debugger code again. Here are a couple of observations:

1. We're not consuming an official version of the debug adapter protocol (https://github.com/microsoft/vscode-debugadapter-node/tree/main/protocol), but our own protocol definition. This makes it hard to keep up with development and to be sure that we're using the correct messages.
2. There is no concept of a debug adapter in our implementation debugger architecture (it is present as an implementation detail only). This makes it hard to get the lifecycle events correct. We have the concept of a DebugSessionConnection and the concept of a "session" in the DebugService, but for the very least, the naming is confusing. Debug adapters are a core concept of the Debug Adapter Protocol and there is nothing wrong with having them present in the architecture.
3. As @paul-marechal's states in the description, it really should not be necessary to override the DefaultDebugService in order to implement the plugins debug facilities. We should have a single debug service and the variability should come in mostly through different kinds of DebugContributions like BackEndDebugContribution and PluginDebugContribution. These can be contributed either through dependency injection or registered dynamically. The consequence would be that the contributions would be responsible for starting debug adapters and establishing connections to them.
4. We should separate the debugger entities and the display of these entities in the UI: right now DebugSession is implmented in a *.tsx file and implements TreeElement.
5. The debug session lifecycle is implemented by the DebugSessionsManager in cooperation with the DebugSession object. It's not always possible to determine whether something happened due to user interaction or because of an event in the debuggee. This makes implementing stuff like lifecycleControlledByParent difficult.

These changes would not affect clients that use plugins to contribute debuggers, but only folks who override the debug service or contribute debuggers through the dependency injection mechanism. I believe the refactoring would be highly useful to make further changes in the debug module easier and the code to be of higher quality.

If we go this route, we should work closely with adopters to make the change as painless as possible.

[paul-marechal]

A couple notes regarding what you wrote about:

1. ✅
2. In the VS Code API, the DebugAdapter interface is basically a DAP connection abstraction: A debug adapter is something that reads and spits out DAP messages. Doesn't matter where the messages are originated from or how the messages are transported. I think our API's first class citizen should be a Debugger interface supporting everything supported by the DAP, and debug adapters would be implementation details hidden behind wrappers to create Debugger instances internally: e.g. const debugger: Debugger = createDebuggerFromDebugAdapter(debugAdapter);
3. ✅
4. In broad strokes: A DebugSession should be wrapping debugger(s?). We should have a DebugWidget/DebugView driving one or several DebugSessions from the UI?
5. No opinion.