Fixes #215, where ByteBuf.nioBuffer() on a value returned via ByteBufProxy.PROXY_NETTY yields zeros.

Root cause (confirming @2018ik)

For zero copy, a read-returned ByteBuf is repointed at LMDB's mmap by overwriting its memoryAddress (ByteBufProxy.out). The ByteBuf's own accessors (getBytes, …) then read the LMDB data correctly, but ByteBuf.nioBuffer() derives its NIO buffer from Netty's separate, chunk-shared backing buffer, which was never repointed — so it reads zeros. That chunk buffer cannot simply be repointed (as @2018ik suggested): it is shared by every pooled buffer carved from the same chunk, so overwriting its address would corrupt sibling buffers.

This is a "pick one" PR

Rather than guess, I've implemented both reasonable fixes as separate commits so you can choose and drop the other:

Commits:

1. test(#215) — repro test pinning the current (buggy) behaviour.
2. feat(#215) — nioBufferView (zero-copy) + test.
3. feat(#215) — nioBufferCopy (safe copy) + tests.

→ Keep both, or drop commit 3 (view only) or commit 2 (copy only). I'll remove the unwanted variant (and its one cross-reference) in a follow-up.

Recommendation

My personal preference is to keep both nioBufferView and nioBufferCopy and document the trade-off clearly (the table above), so callers can pick per use case: zero-copy when the buffer is consumed within the transaction, or the safe copy when the bytes must outlive it. To me that is the cleanest outcome — the two genuinely serve different needs, and offering both (with the lifetime caveat spelled out) is more useful than forcing one.

That said, this is entirely your call. If you'd rather minimise API surface, I'm happy to keep just one — I'd suggest nioBufferCopy as the safe default — or to land only the repro test + docs and add no new API at all.

Notes / testing

• New ByteBufNioBufferTest (4 tests, all green): view reflects data, copy reflects data, copy survives txn+env close (the key discriminator), and the raw nioBuffer() bug is documented.
• Existing ByteBufProxyTest unaffected; fmt-maven-plugin:check clean.
• I did not touch the Netty 4.2 / adaptive-allocator question (Netty 4.2 series and the adaptive allocator. #261); this fix applies to the current pooled path and the same lifecycle reasoning would carry over to an adaptive proxy.