When fixing JAVA-5901, we replaced a pair of invocations:

• io.netty.buffer.ByteBuf.retain&readSlice with a single invocation of io.netty.buffer.ByteBuf.readRetainedSlice
• io.netty.buffer.ByteBuf.retain&duplicate()with a single invocation of io.netty.buffer.ByteBuf.retainedDuplicate()

believing that they are semantically identical based on the API documentation https://javadoc.io/doc/io.netty/netty-buffer/4.2.9.Final/io/netty/buffer/ByteBuf.html#readRetainedSlice(int). 

Expected Result

The duplicated or sliced Netty buffer view should follow shared ref-count semantics with the parent buffer. Releasing the view should only decrement the parent’s refCnt, and the view should remain usable as long as the parent is retained. This should be consistent under both pooled and unpooled allocators.

Actual Result

Under pooled Netty allocators, retainedDuplicate() and retainedSlice() can produce a derived buffer view with an independent ref-count/lifecycle. If that view is released, it becomes unusable even though the parent buffer remains retained. The observed IllegalReferenceCountException (in JAVA-5982) in command logging is a symptom of this unexpected independent lifecycle.

Proposed Change
Replace the specific retainedDuplicate() usage with duplicate().retain() for this duplication site to restore shared-refCnt lifetime behavior under pooled allocators. (the same is applicable to retainedSlice())

Acceptance Criteria

• Revert the Netty buffer duplication/slicing behavior introduced in JAVA-5901, except keep the Netty stream racy buffer leak fix intact.
• Use duplicate().retain() instead of retainedDuplicate() at the affected duplication site(s).
• Use readSlice().retain() instead of retainedSlice() at the affected slice site(s).
• Add/adjust coverage to exercise pooled allocator behavior and prevent regressions (command logging must not throw IllegalReferenceCountException).