Support FixedSizeList RowConverter

[findepi]

Which issue does this PR close?

none

Rationale for this change

This is necessary to support DISTINCT and GROUP BY over fixed-sized arrays in DataFusion.

What changes are included in this PR?

Add DataType::FixedSizeList support to RowConverter.

Are there any user-facing changes?

No

[tustvold]

It should he relatively straightforward to avoid needing to cast and to encode/decode the array directly. This would avoid adding two very heavy dependencies in the form of arrow-cast and by extension arrow-select.

Further, it is actually wasteful to encode fixed size lists in this way, we don't need to var-encode them, we can simply encode the values directly one after each other, much like we do for StructArray.

[findepi]

@tustvold thanks for the feedback!
my thought process was that it might be a niche use-case so I optimized for minimal code size with the intent of best maintainability. However, I take your judgement on the dependencies (also impacting maintainability). Will update.

[findepi]

Updated to remove casts.
There still is variable encoding. A null FSL[n] is now encoded to a null sentinel byte.

[alamb]

Thank you @findepi -- I won't say I fully follow the logic but I did verify the tests and the validation performed and that this seems to follow the pattern of the other converters.

It might also be worth adding a benchmark in arrow/benches/row_format.rs in case someone wants to try to optimize this code more in the future

[alamb]

Just pattern matching, I wonder why this doesn't use the same pattern as List?

Why not

Suggested change

	tracker: &mut LengthTracker,
	lengths: &mut [usize],

(I don't see anything wrong with this I am just curious)

[findepi]

the caller used to operate on lengths: &mut [usize] and that's why list helper functions have this in their API
the caller has been migrated to tracker: &mut LengthTracker, the helper functions for list hasn't been updated.
if this code was inline in the caller (as for eg structs), it would operate on LengthTracker directly.

[findepi]

It might also be worth adding a benchmark in arrow/benches/row_format.rs in case someone wants to try to optimize this code more in the future

I didn't find an example with a normal list to follow. I'd suggest doing this as a follow-up.

BTW with the row format so precisely documented, is the format itself set in stone, or subject to change?

[alamb]

It might also be worth adding a benchmark in arrow/benches/row_format.rs in case someone wants to try to optimize this code more in the future

I didn't find an example with a normal list to follow. I'd suggest doing this as a follow-up.

Makes sense

BTW with the row format so precisely documented, is the format itself set in stone, or subject to change?

I don't know of any policy / discussion on this topic (so the answer is "I don't know").

Part of the rationale to document the Row Format was that it was a pretty tricky thing to make correct -- I don't remember any rationale about not changing it. I also don't know of any use as a long term interchange format

[alamb]

Thanks again @findepi