Fix numerous thread/socket lifecycle crashes and TLS/epoll write-stall busy-loop

Thread/EPoll lifecycle:
- Thread::~Thread() now actually joins/frees its worker thread (was
  empty - the OS thread kept running against already-freed EPoll/Socket
  objects on any early teardown, a confirmed "double free" crash)
- EPoll::~EPoll() calls stop() if never explicitly stopped, for the
  same reason
- epoll_wait() now uses a 1s timeout instead of blocking forever, so a
  worker thread can actually notice isStopping() and let itself be
  joined
- EPoll::processCommand() iterated threads by value, silently
  double-freeing the real vector's Thread the moment each copy went
  out of scope
- ThreadScope gained onThreadStart()/onThreadEnd() hooks (actually
  wired up now - the constructor that was supposed to store the scope
  discarded it) for per-thread C-library init (e.g. MySQL client)

Socket/TCPSocket/TLS:
- Socket::writeSocket(): give up and shut down a connection after 50
  consecutive zero-progress sends instead of retrying forever -
  SSL_ERROR_WANT_READ on a write needs a READ to make progress, but
  resetSocket() re-arms EPOLLWRNORM regardless, which an
  already-writable TCP socket satisfies immediately - a real stuck
  connection generated 55GB, then 12.9GB of debug log this way before
  being caught
- Socket::writeSocket() now honors sendData()'s actual return value
  (previously discarded, entry popped unconditionally after one call) -
  a large response could get silently truncated past what fit in one
  write()/SSL_write() call
- TLS::registerSocket()/sendData()/receiveData(): `initialized` now
  only goes true once SSL_set_fd() has actually succeeded, and
  sendData()/receiveData() check it first - fixes a real SIGSEGV where
  a new session's own queued greeting could reach SSL_write() on a
  different epoll thread before this session's handshake setup had run
- TCPServer::connectionRequest() now performs the TLS handshake ON THE
  ACCEPTED SESSION, not the listening server itself (was building SSL
  state on the wrong object, leaving every session's own `ssl`
  uninitialized)
- TCPServer::receiveData() always uses the plain (non-TLS) read path -
  the listening socket is never itself a TLS peer
- TCPSocket's block-mode literal reading used an unset `blockLength`
  field instead of `blockSize`, and could busy-spin forever on a
  multi-packet literal
- TCPSocket line scanning replaced an unbounded strcspn() (assumes a
  NUL-terminated buffer; read past a non-NUL-terminated receive buffer
  into adjacent heap memory) with a bounds-checked memchr() scan

Protocol/session handling:
- CommandList::processRequest() now case-folds the command keyword
  before lookup - SMTP/POP3/IMAP commands are spec-required to be
  case-insensitive; a client sending "Mail From:" instead of
  "MAIL FROM:" previously failed to dispatch at all
- TCPSession::protocol() no longer drops blank lines while a handler
  has grabbed input (e.g. __SMTP_DATA reading a message body, an IMAP
  APPEND literal) - those handlers depend on seeing blank lines as
  real content, not commands; this silently corrupted any message body
  containing a blank line
- TCPSession's uuid alias fixed: streaming a raw uuid_t via operator<<
  triggered libstdc++'s unsigned-char* overload (strlen() on 16 binary
  bytes, a real stack-buffer-overflow read), and `alias` pointed at a
  stack-local that was already destroyed by the time the constructor
  returned
- INotify::processEvent() only treats event->name as a NUL-terminated
  string when event->len > 0 (per inotify(7)) instead of unconditional
  strlen() on a field the kernel doesn't guarantee is even present -
  a confirmed heap-buffer-overflow read that had been misdiagnosed as
  a MySQL thread-safety issue

TCPSocket.h

@@ -123,6 +123,24 @@ namespace core {
 
       virtual int sendData(const char *data, int length) override;
 
+      ///
+      /// Completes the TLS handshake (SSL_new/SSL_set_fd/SSL_accept) for
+      /// THIS socket's own ctx/descriptor. registerSocket()/acceptSocket()
+      /// are protected TLS members, reachable here via an ordinary
+      /// same-class call - the point of exposing this as a public wrapper
+      /// is so a sibling class (TCPServer, which does not inherit
+      /// TCPSocket-the-session's-particular-instance and so cannot reach
+      /// another object's protected members directly) can still trigger
+      /// the handshake on a specific accepted session from
+      /// TCPServer::connectionRequest(), rather than accidentally running
+      /// it against the listening server socket itself (see that call
+      /// site's own comment for the real, confirmed crash this replaces -
+      /// SSL_read() on an accepted session's never-initialized ssl
+      /// member).
+      ///
+
+      void performTLSHandshake();
+
     protected:
       bool term = false;
       TLSInfo *tlsInfo;
@@ -131,9 +149,28 @@ namespace core {
       char *lineBuffer = NULL;
       int lineBufferSize = 0;
       int lineLength = 0;
-      int blockLength = 0;
       int blockSize = 0;
-      
+
+      // Socket's own `lock` (guards receiveData) and `outlock` (guards
+      // writeSocket/the fifo) are two DIFFERENT mutexes - a thread
+      // handling EPOLLIN and a different thread handling EPOLLWRNORM for
+      // the SAME connection can therefore call SSL_read and SSL_write on
+      // the SAME `ssl*` concurrently. OpenSSL does not support that: an
+      // SSL object must not be used by more than one thread at a time
+      // (even in 1.1.0+/3.x, which dropped the old app-supplied
+      // CRYPTO_set_locking_callback global-locking API entirely - that
+      // API never protected concurrent use of one SSL object anyway,
+      // only OpenSSL's own internal global state). Confirmed live via
+      // dmesg: "traps: apiserver[...] general protection fault ... in
+      // libssl.so.3" during ordinary interactive use. ioLock serializes
+      // just the raw SSL_read/SSL_write calls themselves (see
+      // receiveData/sendData below) - deliberately NOT the surrounding
+      // request-handling, which already nests `lock` before `outlock`
+      // (receiveData's call chain reaches Socket::write(), which takes
+      // outlock) - wrapping any larger scope in ioLock+lock+outlock
+      // together risks recreating that same ordering as a new cycle.
+      std::mutex ioLock;
+
    };
 
 }