Improve tsh ssh error formatting

[fspmarshall]

The tsh ssh command dumps errors that originate from the proxy in an ugly and unformatted state. E.g. when connecting to a node that does not exits:

error: "failed connecting to node one-sshd. \nERROR REPORT:\nOriginal Error: *net.OpError dial tcp 172.10.1.21:3022: connect: connection refused\nStack Trace:\n\t/gopath/src/github.com/gravitational/teleport/lib/reversetunnel/localsite.go:276 github.com/gravitational/teleport/lib/reversetunnel.(*localSite).getConn\n\t/gopath/src/github.com/gravitational/teleport/lib/reversetunnel/localsite.go:189 github.com/gravitational/teleport/lib/reversetunnel.(*localSite).DialTCP\n\t/gopath/src/github.com/gravitational/teleport/lib/reversetunnel/localsite.go:183 github.com/gravitational/teleport/lib/reversetunnel.(*localSite).Dial\n\t/gopath/src/github.com/gravitational/teleport/lib/srv/regular/proxy.go:381 github.com/gravitational/teleport/lib/srv/regular.(*proxySubsys).proxyToHost\n\t/gopath/src/github.com/gravitational/teleport/lib/srv/regular/proxy.go:236 github.com/gravitational/teleport/lib/srv/regular.(*proxySubsys).Start\n\t/gopath/src/github.com/gravitational/teleport/lib/srv/regular/sshserver.go:1222 github.com/gravitational/teleport/lib/srv/regular.(*Server).handleSubsystem\n\t/gopath/src/github.com/gravitational/teleport/lib/srv/regular/sshserver.go:1099 github.com/gravitational/teleport/lib/srv/regular.(*Server).dispatch\n\t/gopath/src/github.com/gravitational/teleport/lib/srv/regular/sshserver.go:1064 github.com/gravitational/teleport/lib/srv/regular.(*Server).handleSessionRequests\n\t/opt/go/src/runtime/asm_amd64.s:1358 runtime.goexit\nUser Message: \n"

It would be nice to have tsh be able to recognize errors originating from the proxy and correctly show well-formatted short/long variants depending on the presence of the --debug flag.

[Joerger]

When I use tsh ssh a node that doesn't exist, I get error: failed connecting to node tp. dial tcp: lookup tp: Temporary failure in name resolution. So has this issue already been addressed?

[webvictim]

I think this is still a problem - it’s just tough to find a case where the error is passed through. I’ll see if I can get a consistent reproduction for the issue.

[zmb3]

See also #4202