Prevent workspace being kept alive when it should not

[code-asher]

There is a problem (which might only exist on Linux) where if the workspace shuts off, VS Code tries to reconnect (which it actually seems to do by reloading the window, from what I have seen), and then as part of that the Coder plugin starts the workspace again, so a workspace stays up forever which is not always what a user wants.

If we can prevent the reload/reconnect to begin with, using a "Do you want to reconnect" popup, that would be great.

However, we might not be able to stop VS Code from reloading the window. If that is the case, we can instead show a "Your workspace is off, should we start it?" popup on the connect phase when the workspace is down, which has a similar effect but a bit delayed since it requires the window to reload and the plugin to get started up again first, and it means you have to answer yes for a first connect as well (unless there is a way for us to tell the difference between a first connect and reconnect).

Also probably worth looking into whether there are existing settings to control this behavior.

Also curious to see if the behavior is different between a workspace shutting down and temporary network instability. Does VS Code reload for the latter case, too? Maybe it makes a few attempts before reloading? Maybe in the first case our proxy command is exiting but in the latter case it stays up? Yeah it might be ssh exiting that is the trigger for the reload.

[code-asher]

Another observation. This issue may or may not happen depending on the timing as we only start the workspace if it is in the stopped state.

So if VS Code reconnects, and the workspace is still shutting down, the start will be skipped and it will wait for the stop build to finish, then say "the workspace is stopped" with an option to restart.

If VS Code reconnects, and the workspace shut down quickly enough, once the plugin starts running the workspace will be already stopped and so it will then be started, and the plugin waits for the start build to finish (leading to the reported issue).

To make this not timing-dependendant, maybe we put this in a loop where we keep trying to get the workspace into a connectable state (in addition to the prompt to actually start the workspace). So basically:

1. Is there a workspace build going on? If so, wait for that build.
2. Is the workspace on? If not, prompt to start the workspace and depending on the response go back to 1 or quit.
3. Otherwise wait for the agent to be ready then connect, or exit if the agent enters some failed/off state.

[Kira-Pilot]

https://coder.zendesk.com/agent/tickets/2970 corresponding zendesk ticket should be updated when this goes out