pickRemoteProcess fails with "Killed by signal 1" when using old ProxyJump

Type: Bug

When doing a pickRemoteProcess over ssh from a WSL centos7 guest to a remote machine using an ssh jump host, the older version of ssh on centos7 exits with signal 1 after running the ps command, and the pickRemoteProcess handler treats this as a fatal error and fails to start debugging.

• vscode running on windows
• remote-wsl guest is centos7
• ssh version is OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017 (doesn't repro with ubuntu-22.04 wsl guest with newer ssh, for example)
• launch.json highlights:

			"processId": "${command:pickRemoteProcess}",
			"pipeTransport": {
				"debuggerPath": "/usr/bin/gdb",
				"pipeProgram": "/usr/bin/ssh",
				"pipeArgs": [
					"-oProxyJump=jumphost",
					"user@remotehost"
				]
			},

• starting debugging results in a popup: "Killed by signal 1"
  
• the Extension Host (Remote) output window shows this error:

2023-10-17 18:15:22.132 [error] Error: Killed by signal 1.

	at /home/user/.vscode-server/extensions/ms-vscode.cpptools-1.17.5-linux-x64/dist/main.js:59549:24
	at ChildProcess.exithandler (node:child_process:412:7)
	at ChildProcess.emit (node:events:513:28)
	at maybeClose (node:internal/child_process:1091:16)
	at ChildProcess._handle.onexit (node:internal/child_process:302:5) extension.pickRemoteNativeProcess {"value":"ms-vscode.cpptools","_lower":"ms-vscode.cpptools"}

• examining the remote-attach output window reveals the source (the last line):

Linux
      aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
    1 systemd                                           /usr/lib/systemd/systemd --switched-root --system --deserialize 21
...
...
27437 bash                                              -bash
Killed by signal 1.

while the ps command was successful, the nested ssh (for some reason) exits with signal 1.

• running the ssh command directly in the centos7 wsl guest shows the same 'error':

user@centos7$ ssh -oProxyJump=jumphost user@remotehost echo

Killed by signal 1.

(this only happens with the older ssh on centos7, newer versions of ssh don't exit like this when using a jump host)

it would be great if the pickRemoteProcess code could ignore this signal 1 exit and continue with parsing the output from the ps command.

Extension version: 1.17.5
VS Code version: Code 1.83.0 (e7e037083ff4455cf320e344325dacb480062c3c, 2023-10-03T16:12:16.321Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Remote OS version: Linux x64 5.15.90.1-microsoft-standard-WSL2
Remote OS version: Linux x64 4.4.0-19041-Microsoft
Connection to 'wsl+centos7' could not be established

Trace the pickRemoteProcess handler associated with the extension.pickRemoteNativeProcess error and compare it with the remote-attach output shown in the report. Reproduce the CentOS 7 OpenSSH 7.4 ProxyJump case, then verify that a signal 1 exit does not discard successfully returned ps output and that process selection can continue.