GH-1236: fix out-of-slice read in ArrowFlightJdbcArray.checkBoundaries

[Arawoof06]

What's Changed

checkBoundaries validates the caller index against startOffset + valuesCount, but index is relative to the start of the array and both call sites add startOffset to it only after the check, so the accepted range is too long by exactly startOffset elements. getArray and getResultSet then read that far past the end of the row's slice. AbstractArrowFlightJdbcListVectorAccessor constructs these from the offsets of the list element being read, so any row of a list column not starting at child offset 0 hands back values belonging to neighbouring rows of the shared child vector, and past the child's valueCount whatever is in allocated-but-unwritten memory. The bound belongs on the relative index, so it is compared against valuesCount instead; that is the same expression as today when startOffset is 0, which is why the existing tests all pass unchanged and only the offset case gets tighter. Added a regression test for each of the two entry points, both of which fail on main.

Closes #1236.

[lidavidm]

@Arawoof06 please rebase.

[Arawoof06]

Rebased onto main, no conflicts.

[Arawoof06]

Rebased onto current main. The CI runs from the August push never ran any jobs, and the new ones are waiting on workflow approval; the Test matrix passes on my fork for this commit.

[jbonofre]

LGTM!

Dropping startOffset from the upper bound in checkBoundaries is the right fix. index is relative to the array's slice (the callers add startOffset afterwards), so the old bound let a slice at a non-zero offset read past its end. The new getArray(1, 3) and getResultSet(1, 3) tests cover that case.

Two older issues are out of scope here, and you may want a follow-up for them. index is treated as 0-based, although JDBC specifies 1-based. A negative count isn't validated.