fix: Properly support multi-word executables set via SSH environment variable

[muchzill4]

Fixes an issue with multi-word, custom ssh command specified via environment variable SSH.
As an example, when export SSH="kitty ssh" is used, some pre-flight checks use only kitty which causes warnings to be logged.
The fix introduces SSHExe type to encapsulate whole multi-word executable.

I've also noticed that detectOpenSSHInfo would never work properly for kitty ssh, nor aliases or scripts, so decided to add a comment while I was in the area.

Before

~/D/v/lima properly-support-multi-word-SSH-env• 
❱ env | rg SSH=
SSH=kitten ssh
~/D/v/lima properly-support-multi-word-SSH-env• 
❱ limactl shell podman
WARN[0000] failed to run [/opt/homebrew/bin/kitten -o GSSAPIAuthentication=no -V]: stderr="Error: Unknown option: -o. Did you mean:\n\t-h\n" 
[user@lima-podman lima]$ 

After

~/D/v/lima properly-support-multi-word-SSH-env• 
❱ ./_output/bin/limactl shell podman
[user@lima-podman lima]$ 

[AkihiroSuda]

Why is this change needed?

[muchzill4]

I'm assuming you mean the introduction of NewSSHExe()? If so, then the idea behind it was to introduce a single, validated entry point for SSHExe instances.

The main motivation is ensuring pre-flight checks, such as exec.LookPath("ssh") has happened. This gives us (more) confidence that the instance you're working with is functional.

Without that, different parts of the code would create SSHExe using a literal, which would bypass custom environment variable or the pre-flight check.

As a bonus, this also cleaned up redundant validation. Previously detectOpenSSHInfo was redundantly calling exec.LookPath(), though the same check might've already happened in the previous version of this function (when it was called SSHArguments).

[muchzill4]

Is test / Integration tests expected to be flaky? I wonder if my change introduced the flakiness, as same test has passed @ 5c3d467.

[AkihiroSuda]

Thanks