[BUG] Netty servers shouldn't reply to WS Close frame immediately

[kciesielski]

When a Close frame is sent to a WebSocket endpoint, then NettyControlFrameHandler immediately replies with a Close frame and closes the context, terminating all in-flight frames that are under processing. This happens in netty-cats and netty-sync, where WebSockets are supported.

Other backends, like http4s and pekko treat the incoming Close frame sequentially, and will reply with a Close only when all currently queued requests are handled.

This is important for cases when incoming frames take some time to process. The sender will probably expect that sending a sequence of inputs termined with Close will handle all that's received and only then close the connection (and respond with Close). Such behavior is expected even if the server's WS endpoint isn't a request->response pipeline, but a pair of disjoint streams - one for processing requests, and one for sending responses.

To fix this in Netty servers, we might need to let Close frames always pass through the NettyControlFrameHandler, and then change OxSourceWebSocketProcessor. Our http4s backend appends a Close frame manually to the end of the stream in WebSocketPipeProcessor, maybe something similar can be synthesized in the sync processor.