Stop Allocating Buffers in CopyBytesSocketChannel

[original-brownbear]

Marked as draft because this is rather an illustration of the issue than the fix I'd like to see here.
The problem with this fix is that it effectively moves us to a 64k read buffer instead of a 1M read buffer (with default settings). This may be a price we can pay for the positive memory effects of reading in smaller chunks without allocations on the IO loop, but it's not great.

The way things currently work, we read up to 1M from the channel
and then potentially force all of it into the ByteBuf passed
by Netty. Since that ByteBuf tends to by default be 64k in size,
large reads will force the buffer to grow, completely circumventing
the logic of allocHandle causing two problems:

1. (this one could simply be fixed by setting the number of bytes in ioBuffer as the attempted read size if it's larger than the capacity of the ByteBuf ... ) This seems like it could break
   io.netty.channel.RecvByteBufAllocator.Handle#continueReading
   since that method for the fixed-size allocator does check
   whether the last read was equal to the attempted read size.
   So if we set 64k because that's what the buffer size is,
   then wirte 1M to the buffer we will stop reading on the IO loop,
   even though the channel may still have bytes that we can read right away.

2. More imporatantly though, this can lead to running OOM quite easily
   under IO pressure as we are forcing the heap buffers passed to the read
   to reallocate. Which with the current default chunk size of 16M means potentially allocating
   16M of buffers without the circuit breaker knowing about it simlply to read ahead from the channel (when reading messages one-by-one would have cost zero additions to the pool).

Relates #49699

[elasticmachine]

Pinging @elastic/es-distributed (:Distributed/Network)

[Tim-Brooks]

LGTM

[original-brownbear]

Thanks Tim!