fix infinite loop in not fully packed bit-packed runs

[tustvold]

Which issue does this PR close?

Closes #1458

Cherry-picked from #1460, will add test and then mark ready for review

Rationale for this change

See ticket

What changes are included in this PR?

See ticket

Are there any user-facing changes?

No

[alamb]

fyi @anliakho2

[alamb]

While I am not super familiar with the code, I did review the test and verified it fails without this code change.

Also the code change makes sense to me.

Also I looked for other places that get_batch is called. I found one in the DeltaBitPackedEncoder that maybe has a similar problem:

https://github.com/tustvold/arrow-rs/blob/fix-rle-infinite-loop/parquet/src/encodings/decoding.rs#L653

It also appears to be used a few other times.

/Users/alamb/Software/arrow-rs/parquet/src/column/reader/decoder.rs
260:                 Ok(reader.get_batch::<i16>(&mut out[range], *bit_width as usize))
/Users/alamb/Software/arrow-rs/parquet/src/data_type.rs
696:             let values_read = bit_reader.get_batch(&mut buffer[..num_values], 1);
/Users/alamb/Software/arrow-rs/parquet/src/encodings/decoding.rs
655:                 .get_batch(&mut buffer[read..read + batch_to_read], bit_width);
/Users/alamb/Software/arrow-rs/parquet/src/encodings/levels.rs
271:                     decoder.get_batch::<i16>(&mut buffer[..len], bit_width as usize);
/Users/alamb/Software/arrow-rs/parquet/src/encodings/rle.rs
418:                 num_values = bit_reader.get_batch::<T>(
471:                     num_values = bit_reader.get_batch::<i32>(
/Users/alamb/Software/arrow-rs/parquet/src/util/bit_util.rs
1062:         let values_read = reader.get_batch::<T>(&mut batch, num_bits);

[alamb]

FWIW this test times out without the code in this PR 👍 which is a good sign to me that it covers the issue

test encodings::rle::tests::test_truncated_rle has been running for over 60 seconds

(I also tried removing each of the two cases -- dict and non dict and the test hung in both)

[tustvold]

I found one in the DeltaBitPackedEncoder that maybe has a similar problem:

In this case the specification is very clear that the miniblock can't be truncated

If there are not enough values to fill the last miniblock, we pad the miniblock so that its length is always the number of values in a full miniblock multiplied by the bit width. The values of the padding bits should be zero, but readers must accept paddings consisting of arbitrary bits as well.

And we return an error a line below if it is, so I think we should be ok.

Good shout to check though 👍

The other cases don't appear to have loops, and GenericColumnReader which drives them will bail out if a page is truncated

[alamb]

I plan to merge this after all (non miri) tests pass