Major Description
There is a race between the startup and arrival of data in the WSTransportProxy class that can lead to failure to create a WebSocket connection because there is no transport listener available when data arrives, at least over AMQP where the SASL header arrives and can't be processed. This has been observed causing Websocket related test failures in the ActiveMQ CI jobs and also in Qpid JMS CI jobs (seemingly only since it was updated to use 5.15.0, though this code hasn't changed since introduction in 5.14.0 it appears?).
When supplied with new frame data, there is a check that the WSTransportProxy instance has already been started, and if not a latch wait is performed until it is before proceeding. This latch is tripped during startup but before the transport listener has been set, meaning it is possible for frame data processing to proceed before the listener is actually set on the transport. Also, the listener field isn't volatile so it could additionally be true that the thread processing the data doesnt yet see a listener which has been set on the transport in the startup thread. Moving the latch trip to after setting the listener should address both those issues.