ce4360f210
Wraps the entire client<->server TCP object stream in TLS, strictly opt-in via an injected SSLContext (null = byte-for-byte the original plaintext behavior). Connection: a ByteChannel _ioChannel indirection (defaults to the raw socket; a TLS-wrapping channel when enabled). Selector registration, connection-pending checks and close still use the raw SocketChannel. Server (PresentsConnectionManager/PresentsConnection/ConnectionManager): setSSLContext/isTlsEnabled; accepted sockets are wrapped in a non-blocking ServerTlsChannel after init+registration; reads/writes route through the io channel. tls-channel NeedsWrite/NeedsRead on write are treated as partial writes (stashed in the existing per-connection overflow queue, retried each timed-select tick — the server never needed OP_WRITE); on read, NeedsRead stays OP_READ and NeedsWrite adds OP_WRITE so the re-dispatch pumps the handshake flush, cleared after a clean read. processAuthedConnections carries the established io channel from the authing connection to the running connection (init() would otherwise revert it to the raw socket mid-session). Client (Client/BlockingCommunicator): Client.setSSLContext; the connected blocking socket is wrapped in a ClientTlsChannel (handshake driven transparently in blocking mode); the Reader/Writer threads share it (one-unwrap + one-wrap, the concurrency tls-channel allows). DatagramChannelReader: fails closed — refuses to bind datagram ports while TLS is enabled (we have no DTLS, so plaintext datagrams alongside TLS would be a footgun; Bang binds zero datagram ports, so this never triggers today).