[lexoliu]

On a buffer ring registered with IOU_PBUF_RING_INC (Linux 6.12), the kernel consumes provided buffers incrementally. When it keeps a buffer for more completions, it sets IORING_CQE_F_BUF_MORE (uapi, v6.12). Extra exposes buffer_id but not this flag (extra/mod.rs), so an op can't tell whether it may give the buffer back, or whether the next completion with the same id continues in it.

This adds Extra::buffer_more() next to buffer_id() and sock_nonempty().

BufferPool itself still assumes each completion uses up a whole buffer. With buffer_pool_flag(IOU_PBUF_RING_INC), the managed ops hand out every completion from the start of the buffer. They also put the buffer back in the ring on drop even while the kernel still holds it. Fixing that means tracking per-buffer offsets in the pool, which is a separate change. This one only makes the flag visible.

The tests receive 5 bytes into a single 4 KiB buffer: buffer_more() is set on an INC ring and clear on a plain one. Both pass on Linux 6.18 and skip where the INC ring can't be registered.

[Berrysoft]

It seems unsafe to set IOU_PBUF_RING_INC.

cc @George-Miao