fix(client): give up on a websocket write the browser doesn't take

[guigs]

A browser that stops reading its websocket freezes every thread using the client, with no error and no timeout. WebSocket#send_message holds @driver_mutex across a blocking @sock.write, and the command timeout (pending.value!(timeout)) only starts once that write returns. When the browser stops reading and a frame is bigger than the kernel socket buffers can hold, the sending thread blocks in IO#write forever. Every other command then blocks on the mutex before it is even sent, so its timeout never starts either. Browser#quit hangs the same way, because Client#close → WebSocket#close needs the same mutex.

We hit this in production: a Sidekiq process whose 6 threads share one browser to render PDFs froze for hours. Its threads sat idle, it logged nothing, and its health checks stayed green. It's reproducible by sending a SIGSTOP to Chrome and then sending a multi-MB command. On my machine the threshold was between 1.3MB and 2.5MB, and it depends on the kernel's socket buffer settings.

The write now uses write_nonblock and waits up to the command's timeout for the socket to take more data. The wait restarts whenever some bytes are accepted, so a slow link that is still moving isn't affected. If the browser takes nothing for that long, the connection is closed, because the frame was cut off midway, and DeadBrowserError is raised. Commands queued behind it fail the same way through the existing dead-connection path. The handshake, close and pong frames aren't tied to a command and keep the old unbounded write; they are a few bytes each.

WebSocket#send_message takes the timeout as an optional positional argument, so existing calls like send_message(id: 1) keep working.