[Optimization] Provide option to reuse Netty's selectors to handle requests

Tapir version: 1.9.11

Scala version: 3.3.3

Describe the bug

A common strategy to boost the performance of HTTP servers in benchmarks is to reuse Netty's event loop selectors to handle requests directly in the thread that receives the payload. This avoids the overhead of switching the execution to another thread and, once the request finishes processing, writing back to the channel is cheaper. If another thread handles the request, Netty also has to use a more expensive mechanism to pass the response back to the selector.

This mode of execution is something that makes sense only for extremely low-latency endpoints with very little CPU usage, which is common for benchmarks. In real production workloads, it's generally better to ensure the event loop is always available to handle payloads otherwise, there can be a large latency cost. We had remarkable latency reductions at Twitter by just switching the request handling to another thread pool. The only services that didn't perform well were the ones that did simple in-memory lookups.

How to reproduce?

I've added an option to the Tapir integration in Kyo to disable the forking. It's possible to check the performance by setting it on/off: https://github.com/getkyo/kyo/blob/main/kyo-tapir/src/main/scala/kyo/server/NettyKyoServerOptions.scala#L17

Start with the request-handling path in Tapir's Netty integration and compare it with kyo-tapir's NettyKyoServerOptions.scala at the linked line. Add an option controlling whether requests reuse Netty's selectors or are forked to another thread, then verify that both modes can be selected and compared for performance.