fix: CompressionTrees diverge from the actual array children

[lwwmanning]

Fixed the following misalignments:

• Sparse compressor would try to compress both indices and values like.child(0)
• FoR compressor would not return an FoR array for constant-0
• Chunked compressor had entirely the wrong children in its CompressionTree
• FSST compressor would compress the varbin offsets but didn't reflect it in the tree
• Dict compressor switched codes and values (because we do codes first, values second everywhere except in the DictArray children themselves, where they are indexes 1 and 0 respectively). Switched the DictArray children, which is a backcompat break, but figured we're better doing the "natural" ordering that people seemingly expect / we do everywhere else in the code base

Also improved the CompressionTree display impl to use TreeDisplay, which is much nicer & more useful for debugging. And I removed the panic_in_result_fn lint, since we ban panic, but assertions are in fact quite nice sometimes.

[AdamGS]

getting ready for non_std Vortex?

[lwwmanning]

I chose to panic rather than making this fallible because this is definitely programmer error (and also, we explore ~all possible permutations of encoding trees in the unit test suite)

[lwwmanning]

this is split off from #1068

[robert3005]

@lwwmanning need to look deeper but the whole idea of compression tree was that you could return a different array than the compressor. The compression tree would send you back to that path

[lwwmanning]

@lwwmanning need to look deeper but the whole idea of compression tree was that you could return a different array than the compressor. The compression tree would send you back to that path

we only did that in the FoR compressor for constant 0, and I'm not sure that's right (i.e., if it's constant 0, the Constant compressor or should win over the FoR compressor with Constant child in this new implementation, rather than saying that we should encode-like with the FoRCompressor)

[lwwmanning]

also, of the 5 things I changed, I'd argued all except the FoR one are clearly bugs

[robert3005]

If we got to for compressor then that means array isn’t constant. Either stats are missing or it’s not constant. Not constant case is likely sparse 0s

[lwwmanning]

If we got to for compressor then that means array isn’t constant. Either stats are missing or it’s not constant. Not constant case is likely sparse 0s

Yep, and in that case we should do Frequency encoding, not FoR

[gatesn]

but assertions are in fact quite nice sometimes.

😱