Interactive Window creation and restore

[rebornix]

Follow up item of https://github.com/microsoft/vscode-jupyter/pull/10785#issuecomment-1182646829

Currently the interactive window is created in an asynchronous fashion (due to the async kernel detection), there is a chance of race condition (InteractiveWindowProvider._windows still empty when multiple clicks happen on Run Cell code lens). Supporting hot exit for Interactive Window also makes the workflow more complex as the hot exit / window restore happens synchronous at extension activation, before we have all notebook controllers ready.

A proposal coming from discussions in https://github.com/microsoft/vscode-jupyter/pull/10785#issuecomment-1182646829 is

• Create InteractiveWindow immediately with owner and mode, push it to _windows in both cases (create or restore)
• Have one explicit start method to get the InteractiveWindow prepared for cell execution, which includes
  • If it's new IW
    • Get preferredController
    • Call interactive.open to create the IW editor in VS Code
    • Start kernel
  • If it's a restored IW, we then have the InteractiveTab
    • Reveal the tab into view (currently we use openNotebookDocument API, in the future we would have Tab API to archive this)
    • Get preferredController and set it as the active controller (maybe we don't need this as the notebook controller provider already tells VS Code which controller to use)
    • Start kernel

[DonJayamanne]

We might want to consider the following scenario as well:

• What happens when IW is restored and user attempts to run some code immediately in the textbox?
  • What kernel would be used at this point (given that our code to set the preferred controller has not yet executed)
• What happens when IW is restored and user changes the kernel immediately (before we've managed to set the preferred controller).

In both cases, we could end up in a situation where kernel A is first selected, then our code runs and we change/update the preferred controller & things might not work as expected. E.g. when restoring its not restored to the right kernel or we end up changing what the user selected.

Basically i'm highlighting the fact that there are still places where we could have race conditions and I'd prefer to avoid all of them completely this way, we don't run into any unknown or difficult to diagnose user bugs or failures on CI ...

[rchiodo]

@rebornix Should we have a meeting about this?

[rebornix]

@rchiodo yes let's arrange one for this.