Verifies the integrety of the projects, as builds are executed immediately after a code change was detected. This plan provides no artifiacts (use a nightly build instead).
OF-3176: Tie shared Netty S2S outbound resource lifecycle to ConnectionManagerImpl
Previously, the shared Netty thread pools for outbound S2S were initialized and torn down from ConnectionListener, causing a race condition where outbound connections could be attempted before the inbound S2S listener had started.
Resources are now initialized in ConnectionManagerImpl.initialize() and destroyed in ConnectionManagerImpl.destroy(), ensuring they are available for the full duration of the server lifecycle.
OF-3176: Fix NPE race condition in DirectTLS channelActive handler
CONNECTION attribute could be null when channelActive fired before handlerAdded had executed on the blockingHandlerExecutor, causing a NullPointerException when attempting to start DirectTLS.
Fix by deferring DirectTLS initialisation behind stanzaHandlerFuture, which guarantees CONNECTION is set before it is accessed. Applied to both inbound (NettyServerInitializer) and outbound (NettySessionInitializer) connection handlers.
OF-3176: Fix DirectTLS channelActive not propagating to downstream handlers after TLS handshake
In both NettySessionInitializer and NettyServerInitializer, the tlsAndAutoReadHandler was unconditionally suppressing channelActive on the directTLS path, including the post-handshake re-fire from NettyConnectionHandler.userEventTriggered(). This meant downstream handlers such as NettyOutboundConnectionHandler never received channelActive after TLS was established.
Fix by inspecting the pipeline for the presence of an SslHandler before deciding whether to suppress or propagate channelActive. On the first call no SslHandler is present yet, so propagation is suppressed and TLS initiation is scheduled as before. On the post-handshake re-fire, startTLS() will have already added an SslHandler to the pipeline head, so the event is forwarded downstream normally.
