Rethink the deprecation of AbstractEpollStreamChannel.spliceTo(...)

All four spliceTo(...) overloads are @Deprecated in 4.2 with "Will be removed in the future" and no further explanation. I asked about this before and was told it was dropped in Netty 5 because "there are flaws" — what are they?

Asking because splice is still much faster for plaintext L4 relay. TCP proxy, 1 MB responses, both channels on the same event loop, epoll, no SSL. Linux x86_64, JDK 21, wrk -c128 -t16 -d10s over loopback, two runs each:

~70% throughput and a much tighter tail. Makes sense: the ByteBuf path does two memcpys per relayed byte and allocates per request, splice does neither. At small payloads the two are equal, so this only matters for large transfers — but that is what a byte relay is for. Loopback exaggerates it since everything shares memory bandwidth; on a real NIC the gap would be smaller, I can't test that.

Nothing else covers this case. FileRegion/sendfile is file-to-socket. IORING_OP_SPLICE is REQ_F_FORCE_ASYNC in the kernel so it always goes to an io-wq worker. That leaves the ByteBuf relay, which is the slower column above.

If the flaws outweigh this, that's completely fair. It would just help a lot to have them documented, along with a recommended alternative for this use case.

Start by reviewing the four deprecated spliceTo(...) overloads on AbstractEpollStreamChannel and the related Netty 5 removal context. Compare the documented alternatives, including FileRegion/sendfile and the ByteBuf relay, against the plaintext L4 relay scenario described here. Done means the splice limitations are documented and a recommended alternative is stated for large transfers.