Fix ProxyJump to support SSH ports and host aliases

[andrewleech]

ET currently fails to connect through jump hosts when the jump host uses a non-standard SSH port or when ProxyJump references an SSH config Host alias.

For example, with this SSH config:

Host jumphost
  HostName jump.example.com
  Port 2222

Host destination
  HostName dest.example.com
  ProxyJump jumphost

Running et destination fails with Could not reach the ET server: jumphost:2022

The issue is that the ProxyJump parsing code was stripping SSH ports from the jump host value:

if (colonIndex != string::npos) {
  jumphost = proxyjump.substr(0, colonIndex);  // Strips :2222
}

Additionally, Host aliases like "jumphost" weren't being resolved to actual hostnames, so ET tried to connect to the alias name instead of the configured hostname.

This PR fixes both issues by:

• Preserving the full ProxyJump value [user@]host[:port] when passing to SSH via -J flag
• Extracting just the hostname from the ProxyJump value for ET socket connections
• Looking up Host aliases in SSH config to get the actual hostname

Tested with the config above. Before the fix et destination fails, after it successfully connects via jump.example.com:2222 (SSH) -> destination (ET).

No breaking changes expected - existing ProxyJump configurations should continue to work, though I don't currently have a working jumphost setup to verify backwards compatibility directly.

[jshort]

@andrewleech now that master has the ci setup fixed, could you rebase so we can make sure the tests all pass. Potentially consider adding a new test case to the connect_with_jumphost but using the ssh path you have fixed.

[andrewleech]

Thanks for the suggestions @jshort
I've rebased and added additional test coverage along with some other cleanups.
While doing this I found some issues with ipv6 address bracket notation support ([::1]:port) in host parsing, so addressed them in a follow up commit with some tests.

[MisterTea]

@andrewleech looks like this is breaking CI?

[jshort]

Thanks for the suggestions @jshort I've rebased and added additional test coverage along with some other cleanups. While doing this I found some issues with ipv6 address bracket notation support ([::1]:port) in host parsing, so addressed them in a follow up commit with some tests.

Oh I see. So in a PR of mine just recently (tunnel/reversetunnel support for bind address and ssh -L/-R notation) I implemented ipv6 bracket parsing of -L/-R arguments. Do you think this logic for the tunnel args and your host parsing for ipv6 addrs in brackets can be shared?

Also maybe an OBOE (note trailing colon):

ssh: Could not resolve hostname localhost:22: Name or service not known