Surface missing enablement of Edit Sessions to user in Continue On flow from web to desktop

[joyceerhl]

Problem

Follow up from #160476 (comment)

1. Have uncommitted changes in insiders.vscode.dev/github/microsoft/vscode
2. Do not have edit sessions turned on locally
3. Continue On > Reopen on the Desktop or Clone Locally and Open on Desktop
4. 🐛 edit session is not resumed locally, and there is no indication that the user was missing some configuration

This is a papercut since the user has to then manually enable edit sessions, and even after doing so requires a window reload or manually running Resume Latest Edit Session for the edits from web to apply to the desktop instance.

Note that settings sync must also be enabled manually across all clients, but I don't think we have any prior art to deal with this scenario where some service or feature needs to be enabled cross-client.

Proposal

My proposal is to contextually ask the user to turn on edit sessions when going from web to desktop with a pending edit session. We can't always ask the user to turn on edit sessions, because a majority of users won't know what edit sessions are. Instead:

1. When using Continue On with an edit session that needs to be applied, the protocol url that is opened should have an additional query parameter. This communicates to the desktop app that it was invoked via a Continue On scenario with an edit session that needs to be applied
2. If the user has already turned on edit sessions, there is nothing further to do here--we go ahead and resume the edit session
3. If the user has not already turned on edit sessions,

   • the first time the desktop application is launched via a Continue On flow, we will display the auth quick pick asking the user to turn on edit sessions with a particular auth session
     

   • if the user ignored the prompt, in future windows, we will not prompt again, but will instead display a badge in the accounts menu which the user can dismiss by clicking on the item (note, we do not display it in the global activity menu)
     

Implementation notes

• Continue On protocol URL invocations going from web to desktop, including URLs which are handled by extension URI handlers, will have an additional continueOn query parameter which indicates that the app launches as part of a Continue On scenario. This query param is appended by core and parsed by core in the 'main' protocol URL handler so that extensions don't have to deal with it (today, both affected scenarios are contributed from Remote Repositories)
• I end up setting the fact that the app launches via Continue On using the environment main service and reading it from the edit sessions workbench contribution. I am still testing whether this works if for e.g. there is already a window open and the Continue On destination is opened in a new window
• Workbench contribution tracks whether it has seen the continueOn state in the environment service using a machine specific application scoped memento key; we don't want to sync this across machines because the user may have multiple machines they need to set up edit sessions on

/cc @joaomoreno @TylerLeonhardt