+str #15904 Ported Tcp IO to new Stream DSL

* Port of Tcp IO to the new Stream DSL
* ~~Ordered shutdown of the server is to be discussed (was missing in the old one as well)~~
* ~~This PR also includes the broadcast fixes for #15948 which can be ignored (will be removed)~~

Fixes #15904
Also, it's interesting that the network usually sits on the outer ends for a server connection, and the server implementation (which binds) has to provide a `Flow[ByteString, ByteString]` (as you suggest). On the client side the network usually sits in the middle and actually provides the `Flow[ByteString, ByteString]` which you could just plug into your flow.

However, who binds or connects in reality doesn't necessarily determine which side the server is and which the client (e.g. vnc reverse mode or FTP passive mode). This means that providing a `Flow[ByteString, ByteString]` may actually be the wrong abstraction here because, in a case like this, the binding side would be the client and would need to first produce output and only then read input which seems awkward to be represented by a `Flow` (if not impossible).

That said, I'd also find it useful to have an API like this but maybe not now.