All Implemented Interfaces:

AutoCloseable

Direct Known Subclasses:

AbstractCBLWebSocket, MessageSocket
```
public abstract class C4Socket
extends C4NativePeer
```
The process for closing one of these is complicated. No matter what happens, though, it always ends like this: Java calls C4Socket.closed (in the JNI, this turns into a call to c4socket_closed, which actually frees the native object). Presuming that the C has a non-null C4SocketFactory reference and that it contains a non-null socket_dispose reference, the C invokes it, producing the call to C4Socket.dispose
I think that this entire class should be re-architected to use a single-threaded executor. Incoming messages should be enqueued as tasks on the executor. That would allow the removal of all of the synchronization and assure that tasks were processed in order.
Note that state transitions come from 3 places. Neither of the two subclasses, MessageSocket nor AbstractCBLWebSocket, allow inbound connections. For both, though shutdown is multiphase.
Core: core request open and can request close
Remote: this is a connection to a remote service. It can request shutdown
Client: the client code can close the connection. It expects never to hear from it again

Class C4Socket