feat: switch to tungstenite-rs

[ctrlaltf24]

Was going to get in the way, plus has more breaking changes (see changelog changes).

Fixes: #115

[ctrlaltf24]

tungstenite-rs is a blocking library (that doesn't support .split). Observed significant performance degradation (25s minimum, peak of 75s) in the following case (client::socket::test::socket_io_integration):

• Callback mode (where there is a separate thread constantly calling poll)
• Attempt to send packets on the clone of the socket returned
• Observe that websocket connection is busy reading
• When a ping packet is received it is possible that the lock switches to the write
• Socket finally sends a message

(keep in mind this same performance degredation is likely on the secure websocket connection as it also doesn't support .split)

Suggested fix: Use some async internally. Currently we are trying to expose a callback interface (typically async), yet only using blocking libraries. Delay until 0.4.0, as it introduces a general performance degradation.

[1c3t3a]

tungstenite-rs is a blocking library (that doesn't support .split). Observed significant performance degradation (25s minimum, peak of 75s) in the following case (client::socket::test::socket_io_integration):

• Callback mode (where there is a separate thread constantly calling poll)
• Attempt to send packets on the clone of the socket returned
• Observe that websocket connection is busy reading
• When a ping packet is received it is possible that the lock switches to the write
• Socket finally sends a message

(keep in mind this same performance degredation is likely on the secure websocket connection as it also doesn't support .split)

Suggested fix: Use some async internally. Currently we are trying to expose a callback interface (typically async), yet only using blocking libraries. Delay until 0.4.0, as it introduces a general performance degradation.

Ahhh shoot. That's bad. I already saw that they don't support split but honestly, but I hoped that it doesn't introduce a performance downgrade of that severity. Introducing async code (via tokio-tungstenite) would make sense, but also brings the downside of the full tokio dependency tree. As you said I would defenetly postpone the issue, but we might stick to websocket for the blocking version...

[1c3t3a]

Superseded by #146.