NIOConnectionPool connectionPoolExhausted: Immediate Failure Versus Back-Pressure Semantics

SwiftNIO's NIOConnectionPool throws ConnectionPoolError.connectionPoolExhausted when all pooled connections are in use and no idle connection is available for a new request. The error is surfaced through the ChannelFuture's failure handler, allowing developers to detect intermittent exhaustion under load. Because the pool size is fixed at initialization and does not automatically grow, exhaustion indicates that the configured maxConnections is insufficient for the current concurrency pattern.

An unresolved behavior concerns whether the pool should back-pressure incoming requests by queuing them until a connection frees up, or continue to fail immediately with .connectionPoolExhausted. The current implementation chooses immediate failure, but the design discussion remains open. Adjusting the pool size after creation requires recreating the NIOConnectionPool, which adds operational complexity when tuning concurrency limits.

What are the intended semantics for .connectionPoolExhausted in SwiftNIO's connection pool design? Should callers treat it as a retryable resource-limit signal or as a hard failure? Is there a documented pattern for safely recreating the pool without disrupting in-flight requests?