Use legacy address mode for juju ssh --proxy

[mjs]

Description of change

The new reachability scan strategy was being used even when --proxy was passed. This makes no sense given that the scan happens from the client yet the SSH connection is going via the controller. This was causing juju ssh --proxy to fail in some cases.

QA steps

$ juju bootstrap google ssh-test 
...
$ juju add-machine
created machine 0
# wait
...

# Verify connections without --proxy still work
$ JUJU_LOGGING_CONFIG="<root>=TRACE" juju ssh --debug 0  
...
[log lines about reachability scan]
...
13:31:37 TRACE juju.utils.ssh ssh_openssh.go:148 running: ssh -o "StrictHostKeyChecking yes" -o "PasswordAuthentication no" -o "ServerAliveInterval 30" -t -t -o "UserKnownHostsFile /tmp/ssh_known_hosts567340662" -i /home/menno/.local/share/juju/ssh/juju_id_rsa -i /home/menno/.ssh/id_rsa ubuntu@104.196.154.242
... (connects successfully)
# Good: direct connection to machine's public address

# Verify --proxy change
$ JUJU_LOGGING_CONFIG="<root>=TRACE" juju ssh --debug --proxy 0
...
[no log lines about reachability scan]
...
13:29:42 TRACE juju.utils.ssh ssh_openssh.go:148 running: ssh -o "StrictHostKeyChecking yes" -o "ProxyCommand /home/menno/go/bin/juju ssh --model=admin/default --proxy=false --no-host-key-checks --pty=false ubuntu@104.196.10.88 -q \"nc %h %p\"" -o "PasswordAuthentication no" -o "ServerAliveInterval 30" -t -t -o "UserKnownHostsFile /tmp/ssh_known_hosts415084587" -i /home/menno/.local/share/juju/ssh/juju_id_rsa -i /home/menno/.ssh/id_rsa ubuntu@10.142.0.3
... (connects successfully)
# Good: connection is to instance's internal address via the controller

Documentation changes

N.A.

Bug reference

https://bugs.launchpad.net/juju/+bug/1669180

[mjs]

$$merge$$

[jujubot]

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju