Make browser detection more robust on Linux

[mjcheetham]

In non-WSL environments we make our checks for a browser more robust by checking for a 'shell execute' handler (like xdg-open).

Previously we just relied on a desktop session (DISPLAY or WAYLAND_DISPLAY), which isn't accurate since in OpenBrowser we require a shell execute handler. The check and implementation are now aligned!

In a Visual Studio Code remote session, we may be able to launch a browser without the DISPLAY environment variable set. This is because VSCode sets the BROWSER environment variable in remote sessions, such that it can forward requests to start a browser to the client machine.

However! There are several types of remote session in VSCode, and the way they handle automatic port forwarding differs slightly. Since a very common case in GCM for launching the user browser is the ability to connect back to GCM via localhost:<port>, we only consider a subset of remote sessions to be able to launch a browser:

• Remote SSH ✅

• Dev Containers ✅

• Remote Tunnel ❌

Sadly, for whatever reason, the remote connection over Microsoft Dev Tunnels does NOT automatically surface a forwarded port to localhost on the client. The forwarded port is only available via the devtunnels.ms URLs.

Dev Tunnels	SSH

Detecting the different types of remote session is tricky as it's not always as explicit as we'd like.

All types: VSCODE_IPC_HOOK_CLI is set.

Dev Containers : REMOTE_CONTAINERS is set.
Remote SSH : SSH_CONNECTION is set.
Remote Tunnel : absense of REMOTE_CONTAINERS and SSH_CONNECTION.

Note, when starting a tunnel server from a regular SSH connection the SSH_CONNECTION variable gets inherited by the tunnel connections themselves! This means we need to also check for the absence of SSH_TTY because the tunnel server unsets this. SSH_TTY is set only in regular SSH sessions.

[dscho]

I like when changes make it easier to debug things!

[mjcheetham]

Sadly, for whatever reason, the remote connection over Microsoft Dev Tunnels does NOT automatically surface a forwarded port to localhost on the client. The forwarded port is only available via the devtunnels.ms URLs.

@kyle-rader-msft are you able to confirm how you connect to the "WaveSpace VMs" (dev tunnel or SSH), and confirm the behaviour of the auto-forwarded ports?

In my testing, forwarded ports in a tunnel remote session are not accessible via localhost:<port> on the client end of the tunnel. This means the localhost:<port> redirect required by MSAL cannot work. I'm curious you seemed to indicate this does work?

I'd imagine because dev tunnel ports are forwarded only to the relay, and not the client. SSH forwarding happens peer-to-peer.

[dscho]

Looks good (even if I would have had a slight preference to keep the Trace changes in their own commit).