When establishing a connection to an SSH server, WebSSH tries to guess
at its encoding using a command sent prior to opening the terminal.
Unfortunately, sometimes this can return data which does not form proper
input for the `encode` function used by `is_valid_encoding` to test
whether the encoding is known.
In particular, we ran in to a case where the server was returning a
string which had a \0 in it when converted to ascii. That raised a
`ValueError` (as opposed to `LookupError`), which was uncaught.
Handle the `ValueError` case as well, treating it as an unknown encoding
so that we fall back on the default.
WsockHandler stores a weak reference to the ssh backend worker. The
worker closes itself if the backend connection closes (e.g. the user
exists the ssh session). That happens in parallel to the websocket
handler processing messages, so it is possible for a message to arrive
when the worker no longer has any strong references, leading to an
exception being thrown.
Handle this case by treating the None worker the same way we do invalid
messages: by simply returning.