WebSockets for netty-cats

[kciesielski]

This PR adds support for Web Socket endpoints in tapir-netty-cats, with all the sub-features like autoPongOnPing, ignorePong, decodeCloseRequests, decodeCloseResponses, and autoPing.

Some remarks:

• The logic for handling control frames (Close, pings/pongs) happens mostly in common tapir-netty code and should work for other Netty-based backends.
• The Cats Effect - specific part is Fs2StreamCompatible, and WebSocketPipeProcessor. Especially the latter, which creates a Reactive Streams Processor[Req, Resp] from user-provided fs2.Pipe[F, Req, Resp].
• The WebSocketPipeProcessor has a workaround to properly handle exceptions thrown in the pipeline. It needs to prevent underlying cancelation mechanisms and instead signal back an error to the Netty channel handler, so that the server properly sends a Close frame. Otherwise the channel closes silently, which also happens in some other servers, like Vert.X, so tests for error handling run only when failingPipe is set to true in ServerWebSocketTests.
• I also added tests for ping/pong handling, which are selectively disabled for some interpreters which don't support them.

In performance tests, latency is on par with our fastest backends (like http4s):

[kciesielski]

@adamw Adding proper handling for non-ws responses in ws endpoints made me think that it's better to remove ReactiveWebSocketHandler entirely. It would realize a majority of logic done by the standard NettyServerHandler plus handshake handling. Instead, I put handshake handling as an additional case in NettyServerHandler. Maybe it's worth extracting the body of initWsPipeline to a function in an object located in the ws package, but I'm not sure about that. WDYT?

[adamw]

@kciesielski yeah if that's feasible, sounds good, might clean up the code :) Not sure about extracting the code to a WS package, you would loose the possibility to call the 500/400 response-generators then? But maybe these should be simply put in yet another "common" object, NettyErrorResponses or such

[kciesielski]

Hmm such extractions require further refactoring, because response handlers are internal implicit classes referencing fields of NettyServerHandler (like request, isShuttingDown, etc.).

[adamw]

@kciesielski let's skip them then ;)

[adamw]

otherwise this PR will end up being gigantic feature + refactor

[kciesielski]

I'm totally on the same page on this 😁

[ghik]

I'm reading through the codebase to get a better mental model of this, but since I'm generally not familiar with it (nor with websockets in detail, for that matter), it might take me some time until I can submit some non-superficial review. Not sure if there's any point in waiting for me :)

[kciesielski]

Thank @ghik, your comments were helpful :)
@adamw waiting for your approval then.

[adamw]

I think in the end code is even simpler now. Great work - let's ship it :)