Draft: reuse allocated buffer in stream reads for TCP/Unix sockets

[seigert]

Similar to #3318 I've changed implementation of SocketPlatform.BufferedReads to reuse allocated ByteBuffer for consecutive reads until filled.

Also I've moved maximum size of read chunk for Socket.reads method to constuctor parameter and made both read and write mutexes optional. Motivation is that if you primary use Socket instance exclusively by reading/writing from one client via either reads/writes or chain of .flatMap then your underlying Channel access is exclusive 'enough' to opt out of mutex guards.

The same logic applies to move of mutex locking for 'reads/writes' over stream itself instead of read/write of separate stream chunk: if we reading from or writing into socket with stream, I think we intend to do this without interleaving with other concurrent reads of writes, if any.

This PR is a draft, because there is still need to change usage of AsyncSocket in UnixSockets and add some tests for implementation without guards.

If this proposed change is acceptable, I'll finish the changes and add tests.

[armanbilge]

I don't want to hold up this work since no ETA for Cats Effect 3.6, but note that these implementations are about to change.

• I/O polling #3240

[seigert]

I don't want to hold up this work since no ETA for Cats Effect 3.6, but note that these implementations are about to change.

Thanks for the heads up!

I've checked your PR and think that it is quite tangential to this one: while implementation of readChunk/writeChunk changes for sure, stream reads/writes looks unchanged, and so the questions of 'should we reuse/reallocate buffers' and 'should be guard each read/write op with mutex or stream as a whole' remain.