In some cases it might get closed but it is not a guarantee like the
comment claims it is.

While we could implement this behavior properly we already close the
connection in the caller so it seems unnecessary.

Still need to figure out a way to test both, but we would rather not add
the ability to select the backend through the API.

Since we might add to the map after it closes, tweak the delete to also
run when the pty closes.

I think this also fixes that issue where if you canceled the context you
pass into Attach it would not do anything since readConnLoop does not
use the context for anything but logging.

We want to send the error from failing to wait for the version command,
not the error from closing/killing the pty or process.

It is possible for the process to immediately exit (for example if you
run `echo hello`), then we would wait for the `version` command to
succeed but it never will because the session is already gone.

If we immediately read to the process then we can tell when it has gone
away and we can abort.

Since we used the same var all I did with my other change was use the
same logger anyway.

Now it will not have the connection ID, which is correct since the
pty is not tied to a single connection.

I moved the conn closes back to the lifecycle, too.

We do not really do anything with it other than just return it, and if
we do need to do something with it we can just do it on the return from
`waitForStateOrContext`, we probably would not need to use it behind the
mutex.

Also we should check the state outside since there is technically no
guarantee an error is set on a state change (although in practice for
close/done there always is, maybe this should be enforced in some way).

…th-screen

🤦