8199120: (so) SocketChannelImpl read/write don't need stateLock when channel is configured non-blocking

[Alan Bateman]

As a follow-on to splitting the code paths for blocking and non-blocking 
I/O, we can do one more optimization to the SocketChannel read/write 
methods to avoid the need to acquire the stateLock when the channel is 
configured non-blocking. For anyone following the recent progress, it 
means that non-blocking operations now only need to acquire readLock, 
all other locking has been eliminated (blocking I/O have been improved 
too but still some synchronization needed to support asynchronous close 
and interrupt).

The changes are small and are relative to the patches for DK-8198928 and 
JDK-8199015 currently under review.

http://cr.openjdk.java.net/~alanb/8199120/webrev/index.html

-Alan