The port number is guaranteed to be set in the config parser,
just like for the host and user, so the unwrap is "OK", but it's
less brittle to handle the error consistent with the others here.
I saw this in the stderr logs when the connection was offline:
```
2021-07-17T01:54:28.036Z ERROR wezterm_ssh::session > Failed to write data to channel: Failure while draining incoming flow. Now
what?
2021-07-17T01:54:28.036Z ERROR wezterm_ssh::session > Failed to write data to channel: Failure while draining incoming flow. Now
what?
2021-07-17T01:54:28.142Z ERROR wezterm_ssh::session > Failed to write data to channel: Failure while draining incoming flow. Now
what?
```
This commit propagates the error rather than logging and ignoring it.
In addition, remove a couple of sources of blocking or panicking
that are now unmasked by this.
Possibly the root cause of https://github.com/wez/wezterm/issues/857
Adding an edge from wezterm-ssh -> async_ossl causes the
openssl vendoring feature selection logic to trigger, which
in turn allows `cargo build -p window --examples` to succeed
again on macos.
The man page states:
> For each parameter, the first obtained value will be used.
but then later says:
> It is possible to have multiple identity files specified in
> configuration files; all these identities will be tried in sequence.
> Multiple IdentityFile directives will add to the list of identities
> tried (this behaviour differs from that of other configuration
> directives).
So that's what this commit does
Similar to 3f6ff534d3, we need to
tickle the mux to detect when the session terminates.
In this case we can relatively simply schedule an async wait without
spawning an additional thread.
Since removing the regular periodic background tasks, we're now
prone to not noticing child processes exiting.
This commit explicictly schedules a thread to do that on Windows
so that we can close a tab as soon as it exits.
