fix: pipe muxer/connection input/output streams in parallel

[achingbrain]

Instead of using it-pipe to tie the inputs and outputs of the muxer and underlying connection together, pipe them in parallel.

When sending 105MB in 32b chunks:

libp2p@0.36.x

testing 0.36.x
sender 3276810 messages 1638409 invocations  <-- how many mplex messages are sent in how many batches
sender 1638412 bufs 68 b                     <-- how many buffers are passed to the tcp socket and their average size
105 MB in 32 B chunks in 9238ms

libp2p@0.40.x

testing 0.40.x-mplex
sender 3276811 messages 32 invocations
sender 6553636 bufs 17 b 27476 ms
105 MB in 32 B chunks in 27450ms

With this patch

testing 0.40.x-mplex
sender 3276811 messages 17 invocations
sender 6553636 bufs 17 b 23781 ms
105 MB in 32 B chunks in 23753ms

With this patch and libp2p/js-libp2p-mplex#233

testing 0.40.x
sender 3276811 messages 1638408 invocations
1638411 bufs 68 b
105 MB in 32 B chunks in 8611ms

Refs #1342

[dapplion]

I have seen this pattern of pipe-ing a duplex in many places of libp2p. Can you please review other usages that can cause the same performance issues?

What was the original point of piping the 4 unrelated together with the duplex / pipe pattern?

[achingbrain]

What was the original point of piping the 4 unrelated together with the duplex / pipe pattern?

I think over the years this has just been ported from node streams to pull streams and then to async iterators and they all have some method of directing the output of one stream to the input of another.

Some minimum amount of benchmarking is necessary, particularly where the code is very low level.