[Feature] Implement Zero-Copy infrastructure in DataQueueCommand #15597

[LI123456mo]

Problem: Currently, the DataQueueCommand in the Triple protocol uses byte[] for data transfer. This triggers a System.arraycopy inside the writeBytes() call when stitching the frame header with the payload. For large messages or high-throughput scenarios, this constant memory copying creates significant CPU overhead.

Solution: This PR refactors the outbound data path to support Zero-Copy transport:

DataQueueCommand: Updated to use Netty ByteBuf. It now uses CompositeByteBuf to stitch the 5-byte Triple header and the message payload without performing a memory copy.

Transport Bridge: Updated AbstractTripleClientStream to wrap outgoing payloads in Unpooled.wrappedBuffer. This ensures that even though the upper layers still use byte[], the transport layer handles them as buffers, enabling "gathering writes."

Why I limited the scope: I have intentionally avoided modifying the PackableMethod and Compressor interfaces in this PR. Updating them to ByteBuf or ByteBuffer would require breaking public APIs and introducing Netty dependencies into core modules. I believe this PR provides the necessary infrastructure for Zero-Copy first; we can discuss evolving the Serialization/Compression layers in a separate follow-up to keep this change safe and backward-compatible.

Tests: Verified that dubbo-rpc-triple compiles and core transport logic remains intact.

[EarthChen]

replace #16072