fix potential UB in ByteBool encoding

[a10y]

Summary

Our existing ByteBool constructor accepts arbitrary bytes as input, and will attempt to transmute it to a &[bool]. If those bytes are not 0x00 or 0x01 that can trigger UB on release builds.

API Changes

We eliminate the ByteBool::as_slice() -> &[bool] method, replacing it with an accessor to the truthy byte values.

We don't really need to access this as a bool-slice anyway since we can do all operations on the bytes and wrap them back up as a ByteBool.

We also eliminate some old From constructors for ByteBool that I think we probably don't want lying around

Tests

No additional tests needed

[a10y]

Hmm, actually this begs the question of, do we want to match Arrow 8-bit Bool representation, or do we want to force it to be a Rust bool?

https://arrow.apache.org/docs/format/CanonicalExtensions.html#bit-boolean

[a10y]

I think this should probably use 8-bit bool instead (i.e. truthy bytes = true, 0x00 = false).

Let me fix this up.

[codspeed-hq]

Merging this PR will not alter performance

✅ 1163 untouched benchmarks
⏩ 1457 skipped benchmarks¹

---

_{Comparing aduffy/bytebool-ub (cd23309) with develop (102de51)}

Footnotes

1. 1457 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩