HDDS-15485. Avoid ByteBuffer.wrap on ChunkBuffer.put(byte[]) path

[yandrey321]

What changes were proposed in this pull request?

Problem

ChunkBuffer exposes put(byte[]) and put(byte[], int, int) as interface default methods that wrap the array in a throwaway buffer and delegate to put(ByteBuffer):

default ChunkBuffer put(byte[] b) {
  return put(ByteBuffer.wrap(b));
}
default ChunkBuffer put(byte[] b, int offset, int length) {
  return put(ByteBuffer.wrap(b, offset, length));
}

Every put(byte[]) on the chunk-write path therefore allocates a short-lived HeapByteBuffer wrapper purely to hand the bytes to the destination buffer. On the hot write path this is per-call garbage that the copy itself does not need.

Change

Override put(byte[]) / put(byte[], int, int) in all three ChunkBuffer implementations so the array is copied directly into the backing ByteBuffer(s) via ByteBuffer.put(byte[], int, int), with no intermediate wrap:

ChunkBufferImplWithByteBuffer (single backing buffer) — buffer.put(b, offset, length).
ChunkBufferImplWithByteBufferList (fixed buffer list) — fills successive current() buffers until the range is consumed.
IncrementalChunkBuffer (allocate-on-demand) — fills successive buffers, allocating at position as needed.
The interface defaults are kept as a fallback for any other/foreign implementation, so behavior is unchanged for callers that don't hit these three concrete types.

Generated-by: Claude Code (Opus 4.8)

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-15485

How was this patch tested?

CI:

• TestChunkBuffer — added coverage for put(byte[]) and put(byte[], int, int) across the single-buffer, buffer-list, and incremental implementations, including multi-buffer-spanning ranges and the bounds/overflow error paths.

• ChunkBufferPutBenchmark + JfrByteBufferAllocations (JFR profiler), 4KB stream-fill into a 64KB-increment IncrementalChunkBuffer (the targeted hot path):

Allocation elimination — the goal of this change:

Direct put(byte[]): 0 ByteBuffer.wrap calls and 0 ByteBuffer allocations — JFR confirms zero ByteBuffer TLAB allocations on this path.
Previous wrap path: 49,430,528 ByteBuffer.wrap allocations per run (one throwaway HeapByteBuffer per put).
Net: ~49.4M wrapper allocations per run removed — a 100% reduction on this path, cutting exactly that much per-write garbage off the chunk-write hot path and the GC pressure it creates under concurrent load.
No throughput cost: ~38 GB/s and ~102 ns/op on both paths across 3 rounds (within run-to-run noise) — the allocation savings come at no measurable performance penalty.

[yandrey321]

@jojochuang @szetszwo could you please take a look?