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.
There are a few notable changes as a result:
* A number of `.ssh/config` options are now respected; host matching
and aliasing and identity file are the main things
* The authentication prompt is inline in the window, rather than
popping up a separate authentication window
Refs: https://github.com/wez/wezterm/issues/457
I can't get this to succeed though; I suspect there may be a lingering
bug from libssh2 and/or trailing support for newer openssh features.
refs: https://github.com/wez/wezterm/issues/457