Simplify

[back2dos]

This is still missing quite a few things (implicit casts and regrouping), but it vastly improves performance for synchronous streams and fixes #20 in the process.

It also makes stream iteration consistently lazy and suspendable.

Which brings me to my main question: what to do with blending? I don't fully understand the use case. It introduces a temporal component that can only be conserved if the blended stream is eager. The only usage I found was tink_websocket, to blend in the pongs in the TcpConnector, but I wonder if there are others.

[kevinresol]

The only usage I found was tink_websocket

That's the only case I remember using it too. It was for automatically chipping in ping-pong messages to keep the connection alive. I guess we can just remove it and let high-level code handle these.

[kevinresol]

How about let us merge this and deal with downstream usage later?

[back2dos]

Actually, tink_io seems quite deeply affected by this. Need to resolve at least #27 to move forward.

[kevinresol]

About websocket blend stream, the idea was that the incoming stream which can contain both signalling messages (ping/pong) and user messages is split into two streams respectively. For the signalling stream it is supposed to be handled internally by the framework i.e. auto ping pong. While the user message stream is passed to developer.

In this particular use case, the blended stream is actually eager because it is eagerly consumed and piped into the wire.

I guess we can live without blended stream, by simply consuming the two streams individually?