RBL/Debugging code cleanup

[roblourens]

• Look at how the debug adapter tracker running the variables view interacts with the KernelDebugAdapter
• Split KernelDebugAdapter into multiple classes that only have one job
  • RBL code cleanup #7416
• Move the DebugAdapterDescriptorFactory into its own class (depends on variables stuff, and not setting global context keys for debug)
• We send disconnect multiple times which triggers errors from the kernel

[DavidKutu]

dump all cells is not working

[roblourens]

Variables cleanup: Currently, the flow is like this

• kernelDebugAdapter sends stackTrace/scopes/variables requests and ignores the responses of those requests
• DebuggerVariables is a DebugAdapterTracker, and updates itself when the variables request goes through
• DebuggingManager sees the variables response go through, and fires onDidFireVariablesEvent
• VariableView listens to that event and prompts the UI to refresh itself

So the logic is distributed in multiple places. It would be cleaner to have DebuggerVariables be responsible for updating itself and knowing what logic is needed to do that, so @DavidKutu and I plan to do it this way instead:

• DebuggerVariables sees the stopped event emitted by the DA
• It sends the stackTrace/scopes/variables requests needed to refresh its variables list
• It fires an event onDidUpdateVariables
• VariableView listens to that event and prompts the UI to refresh

Then we can lose the DA sending variables requests to trigger a side effect somewhere else, and the weird onDidFireVariablesEvent. And this will essentially fix #7365. One issue I can think of is that DebuggerVariables may need to know whether we are in RBL or full debugging, so it knows which scopes to update variables for? Not sure whether that is true or not.

Does this sound ok to you @IanMatthewHuff?

[IanMatthewHuff]

@roblourens and @DavidKutu . I like this cleanup. Currently it feels pretty shoehorned in. In particular DebuggerVariables owning sending and handling the stackTrace ect... requests feels much nicer.

I'd actually love to meet sometime to discuss moving totally off the old Variable View and onto using the VS Code variables control at all times for notebooks and interactive window both in debugging and normal execution. What we are doing now still feels to me like bolting VS Code debugging concepts into a funky old webview control. I'm a bit unsure of how much work that would be, but once the basics are working to not regress current customers that time investment feels better than sinking more time into the webview control.

@roblourens is that something that feels feasible to you? Could we have the VS Code variables control available in a non-debugging scenario where we could have our old non-debugging method of fetching variables (the KernelVariables classes) respect the debug messages?

[roblourens]

Well we wouldn't want to run a debug session all the time. If we show vscode's variables view in some other context, I don't know how that generalizes to other situations. I think we would be talking about something notebook-specific. I suppose that any notebook that has state could use something like this though. Honestly the webview UI feels fine right now. Providing this to other notebooks in general would be a big task but there is no other consumer right now. Maybe Don's TS notebook some day. I dunno if @rebornix feels differently

[roblourens]

Remaining:

• We send disconnect multiple times which triggers errors from the kernel
• The initial dumpAllCells() call doesn't seem to work correctly and triggers errors from the kernel