fix: correctly copy null buffer when making deep copy

[westonpace]

In some situations an array could be sliced in such a way that the array had no offset, but the array's null buffer did have an offset. In these cases we were not deep copying the array correctly and the offset of the null buffer was lost. This does mean, in some cases, the 2.0 writer could write incorrect nulls. However, the input conditions would mean that the user's data would have to originate from rust in such a way that it was sliced like this. It would be impossible for batches from the C data interface or from python to look like this.

[westonpace]

The reason had become a problem (and the reason the test case is testing scalar indices) is that we started using 2.0 to write our scalar indices. The input for 2.0 is the output of a datafusion sort plan which caused the data to be sliced in this way.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.49%. Comparing base (ef9d0c2) to head (cc22232).
Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3238      +/-   ##
==========================================
+ Coverage   78.45%   78.49%   +0.04%     
==========================================
  Files         244      245       +1     
  Lines       84554    85065     +511     
  Branches    84554    85065     +511     
==========================================
+ Hits        66333    66772     +439     
- Misses      15418    15478      +60     
- Partials     2803     2815      +12     

Flag	Coverage Δ
unittests	78.49% <100.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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