Fix: array list values are leaked on nested unnest operators

[duongcongtoai]

Which issue does this PR close?

Closes #10672 .

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

[duongcongtoai]

this will return the underlying low level array, which include the row indices filtered out by limit/offset

[jonahgao]

Nice catch ! Thanks @duongcongtoai

Another simple way to reproduce it is

select unnest(column1) from (select * from (values([1,2,3]), ([4,5,6])) limit 1);

I'm not sure if this is a bug in arrow-rs or by design. It only slices the offset data of the ListArray, without slicing the child data.

[duongcongtoai]

Nice catch ! Thanks @duongcongtoai

Another simple way to reproduce it is

select unnest(column1) from (select * from (values([1,2,3]), ([4,5,6])) limit 1);

I'm not sure if this is a bug in arrow-rs or by design. It only slices the offset data of the ListArray, without slicing the child data.

I think current impl is correct, because the offset values after slicing is still offsetted based on original array. Else we have to do shifting for each offset elements like

Current buffers
            undearneath value: [1,?,3,?,5,6]
            nulls: [1,0,1,0,1,1]
            offset: [0,1,2,4,6]
            logical value: [1] [null] [3,null] [5,6]

Slice(2,2)
            logical values -> [3,null] [5,6]
            offset -> [2,4,6] << 2 = [0,2,4] 
            unearneath_value.slice(2:) = [3,?,5,6]
            nulls.slice(2:) = [1,0,1,1]

[jonahgao]

I think current impl is correct, because the offset values after slicing is still offsetted based on original array. Else we have to do shifting for each offset elements like

I think the shifting operation should be done internally in arrow-rs if needed, as it depends on what the data in the values looks like. Moreover, we don't need to do shifting for FixedSizeListArray.

The current solution looks good to me.