Mutex for ServerSocketChannel#accept and Channel#write / Channel#read

[mschuwalow]

Per https://docs.oracle.com/javase/7/docs/api/java/nio/channels/AsynchronousSocketChannel.html and related docs all of these are unsafe to read / write from concurrently. Currently we don't assist the user with this, and leave them on their own to respect that part of the api.

An alternative approach would be to embed a semaphores in the managed resources that we return.
This would make sure that only one concurrent read / write ever happens.
This of course will have a slight performance penalty in comparison to the current situation, but I believe it is more in line with our policy to provide functionality that makes it hard to shoot yourself in the foot with.

WDYT?

/cc @iravid @pshemass @mijicd

[pshemass]

@mschuwalow mission of this library is to provide "A small, unopinionated ZIO interface to Java NIO.". That assume that someone knows NIO which is unsafe in many ways. So don't want to add this because that is not inline in this mission statement.

@quelgar @jczuchnowski WDYT?

[quelgar]

I'm in favour of leaving this as something the zio-nio user will have deal with in whatever way makes sense for their app. Building in a mutex could be convenient, but how sure are we that will be the ideal concurrency approach for all situations?

[jczuchnowski]

So I think this is something for an "extended" module I suggested on Discord https://discordapp.com/channels/629491597070827530/629498190504132626/641323914097852476