Increase bufferSize for org.xnio.ssl.JsseXnioSsl.bufferPool to avoid issues with the socket buffer being too small when the BouncyCastle JSSE provider is used

When attempting to connect to WildFly via the CLI with the remote+https protocol when using the BouncyCastle JSSE provider, a ConnectException occurs (see ELY-1624). It turns out that the underlying issue occurs in the org.xnio.ssl.JsseSslConduitEngine constructor:

JsseSslConduitEngine(final JsseSslStreamConnection connection, final StreamSinkConduit sinkConduit, final StreamSourceConduit sourceConduit, final SSLEngine engine, final Pool<ByteBuffer> socketBufferPool, final Pool<ByteBuffer> applicationBufferPool) {
...
    if (receiveBuffer.getResource().capacity() < packetBufferSize || sendBuffer.getResource().capacity() < packetBufferSize) {
        throw msg.socketBufferTooSmall();
    }
...
}

In particular, when using the BC JSSE provider, SSLSession.getPacketBufferSize() returns a larger value (20491) than when using the Sun JSSE provider (16921). The values of receiveBuffer and sendBuffer above are set using the org.xnio.ssl.JsseXnioSsl.bufferPool variable which sets the bufferSize to 17408. Since this value is greater than SSLSession.getPacketBufferSize() when the Sun JSSE provider is used, no exception occurs. However, since 17408 < 20491, an IllegalArgumentException occurs when the BC JSSE provider is used.

If we increase the bufferSize that gets set by org.xnio.ssl.JsseXnioSsl.bufferPool, the above code executes successfully and it is possible to successfully connect to WildFly via the CLI using the remote+https protocol when the BC JSSE provider is used.