RunOnVirtualThread should avoid using Netty FastThreadLocals

[franz1981]

During the jackson serialization we currently uses (off-heap) pooled ByteBufs using Netty's pooled allocator, but this could be inefficient, because pooled ByteBuf still uses Recyclers at https://github.com/netty/netty/blob/4ba1c3e7e190bdc9bdd0ece237042f16e843c797/buffer/src/main/java/io/netty/buffer/PooledUnsafeDirectByteBuf.java#L39, which are using https://github.com/netty/netty/blob/4ba1c3e7e190bdc9bdd0ece237042f16e843c797/common/src/main/java/io/netty/util/Recycler.java#L180 which uses FastThreadLocals.

This is visibile in this flamergraphs as well:

Possible solutions are:

1. fixing Netty
2. bytecode rewrite it on us, again
3. thanks to Batching buffer with minChunkSize #32858 we could avoid allocating PooledBuffer(s) for virtual thread(s) and just use unpooled heap-based ones (which doesn't use the Recycler - in short, what Vertx usually does BTW)

[quarkus-bot]

/cc @cescoffier (virtual-threads), @ozangunalp (virtual-threads)

[franz1981]

@cescoffier @dmlloyd I'll soon open something related fast-thread locals vs blocking thread pool as well

[franz1981]

@vietj too

[cescoffier]

Let's avoid (2) - we went that route, it still hurts.