fix: FSST canonicalize when > 2GB of buffers

[a10y]

Fixes a bug where decoding a large FSST array results in an invalid VarBinViewArray.

When you have a large buffer that is FSST compressed, currently we generate a new VBV with the single buffer plus some views built against it. There will be trouble if the buffer is > 2GiB though.

This PR splits out a separate build_views function that takes a max_buffer_len parameter and as it generates views, it splits (zero-copy) the underlying buffer into segments of no more than max_buffer_len.

[codspeed-hq]

Merging this PR will not alter performance

✅ 1254 untouched benchmarks
⏩ 1254 skipped benchmarks¹

---

_{Comparing fsst-canonical (6a79200) with bufferhandles (e09bc36)}

Footnotes

1. 1254 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. ↩

[a10y]

This is actually very conservative, and doesn't account for the presence of inlined strings.

There isn't really a way to get around this without lots of data copying

[a10y]

(FWIW this is already a problem on develop as well, except there everything lives in one giant buffer which sometimes is too large for VarBinView)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.39%. Comparing base (e09bc36) to head (6a79200).

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.