Protocol issue with WAIT_FOR_USER_CONFIRM

[friedger]

The current protocol is based on request-response flow:

1. Client sends data and Ryder returns a response, that can be SEND_INPUT, or OK, or WAIT_FOR_USER_CONFIRM
2. This can happen a few times
3. After the last response the connection is closed
4. If the response takes too long the connection times out and the flow ends with an error

The last points (4.) usually happens when the user has to confirm, because timeout should be < 1s.

[MarvinJanssen]

The operation should be straightforward, the bridge acts as "pipe" and passes along any bytes it receives.

So client -> bridge -> Ryder and Ryder -> bridge -> client.

The bridge is idle until it receives a WebSocket connection, then it opens the serial port to the Ryder and keeps it open until the WebSocket connection closes. It does not need to deal with the protocol.

If the Ryder disconnects while in use (serial port connection closes unexpectedly) then the bridge should send a special error code to the WebSocket connection so that the app can recover.

[MarvinJanssen]

Addressed in #13