Throw SocketException on ERR_SSL_SYSCALL. (#430)
Throw SocketException on ERR_SSL_SYSCALL. (#430)

SSLSocketTest#test_SSLSocket_interrupt_readWrapperAndCloseUnderlying
is failing periodically on our internal continuous builds, and it
appears to be happening due to a race condition.

The test is testing what happens when an SSLSocket that's wrapping an
underlying Socket is blocked on a read and then underlying socket is
closed by another thread.  There appears to be a race condition
between the OS waking up the reading thread and the write of -1 to
java.io.FileDescriptor's private field.  If the reading thread wakes
up and proceeds past the check of the file descriptor's validity
before the field write is visible, then it will attempt to call
SSL_read() and get ERR_SSL_SYSCALL, and it responds by returning -1,
whereas the test expects SocketException to be thrown (which it does
if the file descriptor is invalid).

This changes the code to always throw SocketException when
ERR_SSL_SYSCALL is reported with a return value of 0, which the
BoringSSL docs say happens "if the transport returned EOF", which
should mean the file descriptor is closed.
google/conscrypt,google/conscrypt,google/conscrypt,google/conscrypt,google/conscrypt,google/conscrypt