fix[vortex-array]: fix panic caused by take on listview during compression

[asubiotto]

If a ListView is a child of a Dictionary which is canonicalized during compression, Take is executed on the ListView and subsequently its validity slice. This could result in a lazy FillNull array wrapping the validity which was never executed, causing a panic on serialization "Array vortex.fill_null does not support serialization". This PR executes the validity on rebuild, similar to how offsets/sizes are already executed implicitly via to_primitive.

Summary

Fixes a panic writing complex nested types -> dict<struct>

Testing

A high-level regression test was added

[asubiotto]

I still need to clean this PR up a little, but wanted to see if the direction was appropriate. Is there a more ergonomic way to execute the validity? I see validity.execute() but I think that requires LEGACY_SESSION.create_execution_ctx() or something. Is that preferable?

[codspeed-hq]

Merging this PR will degrade performance by 10.2%

❌ 1 regressed benchmark
✅ 979 untouched benchmarks
⏩ 1466 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	map_each[BufferMut<i32>, 128]	770.6 ns	858.1 ns	-10.2%

---

_{Comparing asubiotto/fillnull (6f59c9a) with develop (a332796)}

Footnotes

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

[joseph-isaacs]

Ideally we would fix this at the problematic call sight in the compressor. Since we don't want to force evaluation of the mask in the scan path

[asubiotto]

Ideally we would fix this at the problematic call sight in the compressor. Since we don't want to force evaluation of the mask in the scan path

I think I might need a pointer. This fill null is a result of a take caused by canonicalization of an outer dict in the compressor. I believe we want this fill null to not be eagerly evaluated in a take to not affect the general path. AFAIU, we already evaluate offsets/sizes in rebuild and were just not doing so for validity, so in my mind rebuild is the place to evaluate this. Do we rebuild on scans even if the type matches? That seems expensive for other reasons if so.

[joseph-isaacs]

This is the fix: https://github.com/vortex-data/vortex/pull/6797/changes

[asubiotto]

This is the fix: https://github.com/vortex-data/vortex/pull/6797/changes

Ok, thanks! Much cleaner

[asubiotto]

Superseded by #6797