Add "script" connection type

[CGamesPlay]

Presently the Remote OSS extension supports a "manual" host type, where the user sets up a tunnel to the remote extension host themselves. I want to add a "script" type, where the user can specify some shell scripts that do this for them. Here's my proposal:

The configuration for a "script" host is similar to a "manual" one with the following differences:

• listenScript is added, which is a shell script that sets up a listener.
• localDirectory is added, which specifies the local directory to run scripts in.
• additionalScripts is added, which is a set of {name, script} objects that allow the user to perform additional behaviors ("restart remote machine", "recreate dev container" or whatever else is useful for the user). These scripts run locally just like the listenScript, and exposed as custom commands in the command palette.
• And finally connectScript is added, which is exclusive with host/port/listenScript. This script is executed locally and is expected to establish a connection to an HTTP server over stdio. When specified, the remote extension host communicates using this script instead of a network connection.

This last one seems a bit weird, but it's because when working with devcontainers, we can't actually add port forwards without recreating the container. The only way to get a channel into a devcontainer that's already running is over stdio and docker exec. This is how the Microsoft Remote - Dev Containers extension works and it works fine with Remote OSS as well (although it presently requires using netcat/socat to forward network connections over a docker exec channel).

So, with these changes, a user will be able to specify the scripts needed to connect to a remote, and can have vscode run the scripts for them. Disconnections are going to be a bit tricky: I'm thinking that the listenScript/connectScript are expected to exit to indicate a disconnection event, and the extension will rerun them. This is tricky to do for the listenScript, so the extension will probably also just kill it when it detects a disconnection event itself.

Would a pull request implementing these features be accepted? If not, I can just make a new extension. Let me know. Thank you!

For those curious how to get Remote OSS working with dev containers today, I'm using a custom vscodium-server script on my laptop that I combine with SSH and the official devcontainer CLI to open a remote devcontainer. Remote OSS is supported today by using something like vscodium-server listen "devcontainer exec -- sh -c"

[xaberus]

Would a pull request implementing these features be accepted? If not, I can just make a new extension. Let me know. Thank you!

I think such a feature is definitely in the scope of Remote OSS. I initially wanted to have similar functionality but the initial prototype worked just too well for my purposes. (I do not know how big the user base is right now and what their use cases are...)

I do not have too much time to work on this right now myself. I should be able to find some time to review your PR, though.

[CGamesPlay]

I wanted to give an update on this. I ended up using a different approach, which is more limited, but works for me.

I have a custom script that sets up a variety of port forwards. The built-in port forwards for VSCode are unreliable, so I don't use them. Instead, I use socat in a script that I wrote for each port I want forwarded. I do a similar thing for ssh-agent and for the VSCode REH. This step is janky, and I would love to see a generic open-source port forwarding software that worked like VSCode's built-in one without being built into VSCode (and hopefully that works better than the built-in one). For anyone interested, it happens in the @env script in my dotfiles.

To actually open VSCode, I set up a single remote in remote-oss, on port 4444. My @env script is configured to listen on this port and run the vscodium-server install/connect commands. That script lives in vscodium-server. This works but the configuration is so complex I don't really think anybody else would want to use it.

If I revisit this in the future, I would drop the listenScript and only use connectScript, and I would put a version of the vscodium-server script into this extension, so that ideally most remotes would be 1-line scripts.