Improve `RunLengthBitPackingHybridDecoder.readNext` to avoid per-call buffer allocation and `DataInputStream` wrapping

从 parquet-column/src/main/java/org/apache/parquet/column/values/rle/RunLengthBitPackingHybridDecoder.java 开始，重点查看第 94–98 行附近 readNext() 中的 PACKED-mode 路径以及现有的 TODO。跟踪缓冲区和输入读取的使用方式，然后运行相关的 decoder 测试。当重复调用 PACKED-mode 时能够复用大小足够的缓冲区，而不会为每次调用创建 DataInputStream 包装器，同时保持解码行为不变，即表示完成。

Describe the enhancement requested

RunLengthBitPackingHybridDecoder.readNext() allocates a new int[] and byte[] on every PACKED-mode call. In workloads that decode many bit-packed runs (definition levels, repetition levels, RLE-encoded integers), these allocations dominate the read-side allocation profile. The upstream code even acknowledges this with a // TODO: reuse a buffer comment.

Problem 1: per-call buffer allocation

Lines 94–95 allocate fresh arrays on every PACKED-mode readNext():

currentBuffer = new int[currentCount]; // TODO: reuse a buffer
byte[] bytes = new byte[numGroups * bitWidth];

currentCount is always numGroups * 8, and numGroups is typically small (1–16 groups = 8–128 values per run). These allocations are individually modest but occur thousands of times per column chunk — once per bit-packed run. In a 180M-row merge with multiple integer/boolean columns, the cumulative allocation is substantial.

Since currentCount varies between runs (different numGroups values), the fix retains the field-level int[] and a new field-level byte[], growing them only when the next run requires a larger buffer.

Problem 2: per-call DataInputStream wrapping

Line 98 creates a new DataInputStream(in) on every PACKED-mode call:

new DataInputStream(in).readFully(bytes, 0, bytesToRead);

This allocates a DataInputStream wrapper object per call just to access readFully(). A private readFully() method on the decoder itself eliminates this allocation and the virtual dispatch through the wrapper.

Component(s)

Core