perf: Fix quadratic behavior of to_array_of_size

[neilconway]

Which issue does this PR close?

• ClosesScalarValue::to_array_of_size is slow for StringViewArray with many buffers #20458.
• ClosesAvoid deep copying Utf8View array buffers in ScalarValue::to_array_of_size() #18159.

Rationale for this change

When array_to_size(n) was called on a List-like object containing a StringViewArray with b data buffers, the previous implementation returned a list containing a StringViewArray with n*b buffers, which results in catastrophically bad performance if b grows even somewhat large.

This issue was previously noticed causing poor nested loop join performance. #18161 adjusted the NLJ code to avoid calling to_array_of_size for this reason, but didn't attempt to fix the underlying issue in to_array_of_size. This PR doesn't attempt to revert the change to the NLJ code: the special-case code added in #18161 is still slightly faster than to_array_of_size after this optimization. It might be possible to address that in a future PR.

What changes are included in this PR?

• Instead of using repeat_n + concat to merge together n copies of the StringViewArray, we instead use take, which preserves the same number of buffers as the input StringViewArray.
• Add a new benchmark for this situation
• Add more unit tests for to_array_of_size

Are these changes tested?

Yes and benchmarked.

Are there any user-facing changes?

No.

AI usage

Iterated on the problem with Claude Code; I understand the problem and the solution.

[neilconway]

Benchmarks:

group array-of-size-opt array-of-size-vanilla
----- ----------------- ---------------------
list_to_array_of_size/1_buffer/1024 1.00 1870.0±30.72µs ? ?/sec 3.77 7.1±0.05ms ? ?/sec
list_to_array_of_size/1_buffer/256 1.00 337.9±4.16µs ? ?/sec 1.77 599.8±5.17µs ? ?/sec
list_to_array_of_size/50_buffers/1024 1.00 1945.4±23.28µs ? ?/sec 65.93 128.3±1.06ms ? ?/sec
list_to_array_of_size/50_buffers/256 1.00 364.7±4.31µs ? ?/sec 22.76 8.3±0.07ms ? ?/sec

[neilconway]

I see #18159 already exists for this issue; I'll be optimistic and claim this PR closes it... 😅

[neilconway]

We could consider backing out the special-case logic in NLJ that was introduced in #18161, but that will require some consideration and benchmarking first. I tried a quick hack to remove the NLJ workaround but it hurt performance on a microbenchmark by ~15%

[comphead]

@Dandandan FYI

[comphead]

Thanks @neilconway the solution is elegant and makes a lot of sense

[Jefffrey]

Would it be better to explicitly check that arr.len() == 1 so we don't need to cover edge cases that aren't meant to occur? (Which can lead to a bit simpler/readable code here)

[neilconway]

Personally, I'm inclined to leave it as-is: with the comment giving some examples, the behavior seems reasonably clear to me, and it's not more code to handle the arr.len() > 1 case. But lmk if you disagree.

[alamb]

Looks good to me -- thanks @neilconway and @Jefffrey