Reconsider requirements for `WebSocketConnection.incomingFrames`

[joffrey-bion]

The interface currently guarantees that it's ok to collect multiple times the incomingFrames, as the frames that arrive in the meantime are buffered and not lost. However, this means that this flow always has to be hot. Any custom implementation of WebSocketConnection has to provide a hot flow based on a channel fed by a coroutine in order to honor that (this includes the wrapper that handles reconnections). Otherwise, calls to first() and other terminal operators can cancel the flow, and prevent further collections, which may be a problem depending on the implementation.

This behaviour is heavily relied upon by tests, which use incomingFrames.first() extensively.

We should consider what to do with this abstraction. Its current state would be better expressed with a Channel to be frank (which was the initial design). The goal behind moving to Flow was to provide a more fluent API and allow to wrap WebSocketConnection in a cold way. If we still have to launch coroutines and keep things hot, we should express that requirement with a Channel API.

The best would probably be to remove the requirement from the interface, but that could break some code.