chore: add unchecked array builder methods

[Rich-T-kid]

Which issue does this PR close?

• Closes Create new_unchecked construction methods for all array types #10244.

Rationale for this change

we can avoid un-needed validation at callsites by using new_unchecked() instead of new().

What changes are included in this PR?

added missing new_unchecked methods for PrimitiveArray, BooleanArray, GenericListArray, FixedSizeListArray, FixedSizeBinaryArray and MapArray.

Are these changes tested?

n/a no call sites have been changes yet.

Are there any user-facing changes?

users now have the option to construct these arrays without validation but it must be done within an unsafe block.

[Rich-T-kid]

A follow up PR will wire up call sites that don't ned the validation that new() provides for new_unchecked(). decided not to include it here to make it easier to review

[Jefffrey]

looking at these now, i wonder if we omitted having these because it only really skips some constant checks (i.e. we're not validating per element, we just have some cheap len checks) 🤔

especially for primitive & boolean arrays, maybe having less of a surface area is actually better since we're just skipping a single len check (well option + len check)

thoughts?

[Rich-T-kid]

looking at these now, i wonder if we omitted having these because it only really skips some constant checks (i.e. we're not validating per element, we just have some cheap len checks) 🤔

especially for primitive & boolean arrays, maybe having less of a surface area is actually better since we're just skipping a single len check (well option + len check)

thoughts?

@Jefffrey yea I generally agree with having less of an api surface, especially in this case where we would force callers to have unsafe blocks for minimal value.

i'm not entirely opposed to the idea of keeping these methods to fit in with all of the other array new_unchecked() methods.

[alamb]

especially for primitive & boolean arrays, maybe having less of a surface area is actually better since we're just skipping a single len check (well option + len check)

thoughts?

I think personally it would be better to have consistent APIs though the different array types (even if the difference between try and try_new is minimal for some types). Mostly I think it is better because then the API is more consistent and we don't have to remember why we need to use unsafe for StringView but just new for BooleanArray, as an example

[alamb]

Looks good to me -- thank you @Rich-T-kid and @Jefffrey