Non-blocking pipes still appear to be isBlocking

[Charles Oliver Nutter]

While investigating a JRuby bug report today, I discovered that
despite pipe streams being set O_NONBLOCK at a native level, the NIO
AbstractSelectableChannel.nonblock flag is still false.

This leads to a situation where we have an IO channel that is
non-blocking (at a native level) but claims it is blocking. Forcing it
back to blocking then requires both setting and clearing that flag.

https://github.com/jruby/jruby/issues/8082

I am currently assuming this is intentional; the stream is supposed to
still *appear* to be blocking, and calls expecting blocking behavior
use some sort of select loop:

https://github.com/openjdk/jdk/blob/master/src/java.base/unix/classes/sun/nio/ch/SourceChannelImpl.java#L310-L315

Can anyone confirm that this was an intentional move? It is a bit ugly
to have to call `setBlocking` twice to actually clear the native
O_NONBLOCK.

(And yes, I know the implications for vthreads; this is for a user
with legacy code expecting child process pipe streams to be blocking
by default.)