feat: websocket reconnect

[simone-sanfratello]

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

---

The goal of this PR is to add reconnection capability on the websocket proxy.

This would be the first of a series of PR, I'm going to

• update deps
• refactor websocket code
• introduce connection on timeout on first connection, with the same reconnection logic
• add more test on websocket cases and events

[climba03003]

I am confused, why reconnection should happen in proxy but not the client?

[mcollina]

The goal of this feature is to allow for the proxy to reconnect the socket in case the origin process has to (gracefully or ungracefully) shut down.

[climba03003]

Max retries should be limited by default.
There is no reason to reconnected unlimited since in reconnecting period the client may continue sending data. The data will buffered in stream unlimited.

[simone-sanfratello]

The intention is to keep the connection alive, assuming the error messages are being monitored, that's why I set Infinity

We can remove the default value as Infinity, but in that case we can't set an arbitrary default value, it really depends by the context, ping interval, reconnection delay and so on

[mcollina]

I agree. Those should be limited, possibly to 30 seconds.

[climba03003]

I would like to add a test for buffering data when reconnecting.
If we lost data in that period of time, this feature may not be very useful.

[simone-sanfratello]

I think buffering messages is out of scope, in that case we need a storage, and the logic for retrieving is not responsibility of the proxy.
I've just introduced onTargetRequest and onTargetResponse specifically to handle data that are lost due to disconnection.

[mcollina]

I think it would need a way to buffer incoming message or at least have some sort of callback to deal with them if one so desires.

[mcollina]

lgtm

[simone-sanfratello]

I would like to add a test for buffering data when reconnecting. If we lost data in that period of time, this feature may not be very useful.

I'd do that using hooks, I'm adding an example

[simone-sanfratello]

You can see the example. In that case, using a defensive strategy, messages are sent more than once, but using hooks we can custom logic on it

[mcollina]

lgtm