Complete stream write ChannelFuture on the actual write of a Muxer frame

[Nashatyrev]

The issue closely relates to #282

The problem:

When writing anything to a stream [child] Channel there is an associated ChannelFuture (either passed to or returned from the corresponding write() method).
That ChannelFuture should be completed when the associated message buffer is flushed to the wire. In other words when the associated muxer frame(s) write operation is completed. In yet other words when any buffer(s) associated with the message are released.

That allows various backpressure mechanisms to function correctly on the client side

Currently a stream write ChannelFuture is completed earlier here:

jvm-libp2p/libp2p/src/main/kotlin/io/libp2p/etc/util/netty/mux/MuxChannel.kt

Line 47 in 0981ec6

buf.remove()

So it happens effectively right upon a stream Channel.flush() call. Thus even when the client code is respecting backpressure, i.e. writes the next chunk of data (e.g. writes the next Ethereum block in a batch) only after the previous write was completed, it could still overflow write buffers.

E.g. for the mplex muxer internal Netty write buffers are filled up if the remote reader is slower than local writer
E.g. for the yamux muxer it's internal stream write buffer is filled up

[Nashatyrev]

The fix complicated by the following:

jvm-libp2p/libp2p/src/main/kotlin/io/libp2p/etc/util/netty/mux/MuxChannel.kt

Lines 35 to 52 in 0981ec6

	override fun doWrite(buf: ChannelOutboundBuffer) {
	while (true) {
	val msg = buf.current() ?: break
	try {
	if (localDisconnected) {
	throw ConnectionClosedException("The stream was closed for writing locally: $id")
	}
	// the msg is released by both onChildWrite and buf.remove() so we need to retain
	// however it is still to be confirmed that no buf leaks happen here TODO
	ReferenceCountUtil.retain(msg)
	@Suppress("UNCHECKED_CAST")
	parent.onChildWrite(this, msg as TData)
	buf.remove()
	} catch (cause: Throwable) {
	buf.remove(cause)
	}
	}
	}

doWrite() is the only entry point in the AbstractChannel supposed to handle flush operation. It receives ChannelOutboundBuffer where the only way to get the next buffer is calling remove() which in turn completes corresponding write operation ChannelFuture

Not sure if the AbstractChannel design is suitable for child channel usage scenarios at all

[Nashatyrev]

Another potential problem:
Channel.Unsafe.outboundBuffer() returns ChannelOutboundBuffer which is a final class.

[Nashatyrev]

Test and draft attempt trying to address the issue: ad6c2d3