[FEAT] Support parquet RLE decoding for booleans

[desmondcheongzx]

#3329 shows that we do not currently support reading boolean values from parquet files when they are RLE-encoded.

This PR adds support for this.

[codspeed-hq]

CodSpeed Performance Report

Merging #3477 will not alter performance

_{Comparing desmondcheongzx:parquet-boolean-rle-decoding (5c447f8) with main (de4fe50)}

Summary

✅ 17 untouched benchmarks

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.35%. Comparing base (573f76f) to head (5c447f8).
Report is 25 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3477      +/-   ##
==========================================
- Coverage   77.49%   77.35%   -0.15%     
==========================================
  Files         687      696       +9     
  Lines       84483    84851     +368     
==========================================
+ Hits        65474    65637     +163     
- Misses      19009    19214     +205     

see 117 files with indirect coverage changes

[samster25]

why do you have to do this memcpy thing?
and not just do u32::from_le_bytes(pack)

[desmondcheongzx]

Ah turns out that this was because from_le_bytes expects a fixed size array instead of a slice of bytes.

We can do

let bytes = pack.try_into().expect("Parquet should always encode u32 values");
let value = u32::from_le_bytes(bytes);

which will do a runtime check that the slice is [u8; 4], which would still be faster than copying the bytes over.

[desmondcheongzx]

As discussed offline, unfortunately in some cases pack contains less than 4 bytes (test_invalid_utf8_parquet_reading contains an example) so we can't do this.. reverting to the state prior that does byte-wise copying.