Test DebugAdapterTracker API

[weinand]

Test for #55945:

• anyOS: @roblourens

Complexity: 2

Authors: @weinand

The LiveShare team asked us to provide API to "tap" on the DAP message flow so that they no longer need to wrap or proxy DAs (which is problematic because the VS Code debugger always sees a LiveShare DA instead of the real DA and all DAP traffic has to go through the LiveShare DA).

We've added new proposed extension API to "tap" the DAP messages flowing between VS Code and debug adapters:

https://github.com/Microsoft/vscode/blob/88b85b66c3abc225d09696a0943aa652a83cfdc5/src/vs/vscode.proposed.d.ts#L560-L567

With this API LiveShare could tap the traffic and VS Code would not be affected by this in any way.

A side effect for registering a tracker for a specific debug type (or '*') is that debug adapters for that type no longer run in the renderer, but are automatically started from the extension host (this can be easily verified by VS Code's integrated Process Viewer). We do this to minimise additional round-trips between EH and VS Code.

Here is an example for a generic DAP tracer for all debug types:

vscode.debug.registerDebugConfigurationProvider('*', {
  provideDebugAdapterTracker(session: vscode.DebugSession, folder: WorkspaceFolder | undefined, config: DebugConfiguration, token?: CancellationToken): ProviderResult<vscode.IDebugAdapterTracker> {
    return {
      startDebugAdapter: () => console.log(`startDebugAdapter: ${session.id}`),
      fromDebugAdapter: m => console.log(`<=== ${JSON.stringify(m, undefined, 2)}`),
      toDebugAdapter: m => console.log(`===> ${JSON.stringify(m, undefined, 2)}`),
      debugAdapterError: err => console.log(`debugAdapterError: ${err}`),
      debugAdapterExit: (code, signal) => console.log(`debugAdapterExit: ${code}`),
      stopDebugAdapter: () => console.log(`stopDebugAdapter: ${session.id}`)
    };
  }
});

• verify that this works as described.
• verify that you can register multiple trackers.

In addition:

• provide API feedback. Do you have a better name than "provideDebugAdapterTracker"?
• think about how this could influence our "vscode-debugadapter"-based tracing story (which only works for node.js based DAs). Should we use a DA-tracing extension for this? It could be built-in to be always available. Benefit: it would work even if no launch.config is available (see Need a way to get logs from the DA when there is no explicit launch config #47774). Drawback: it would only log DAP messages, no additional information.

[roblourens]

Drawback: it would only log DAP messages, no additional information.

Yeah, there might be some case where someone just wants to see the DA traffic, like how we can see the LSP traffic in an output channel, but for my development, I want one file with vscode/DA traffic and Chrome/DA traffic and internal DA logging.