Arrow compute kernel regards selection vector

[yjshen]

Is your feature request related to a problem or challenge? Please describe what you are trying to do.

It would be great if the arrow compute kernel could regard a selection vector. Then users won't need to create slices over the existing arrays before applying computations with the compute kernel.

Describe the solution you'd like

A set of new compute APIs that takes a selection vector as the second argument.

For example:

pub fn sum<T: ArrowNumericType>(array: &PrimitiveArray<T>, selection_vector: &BooleanArray) -> Option<T::Native>
where
    T::Native: ArrowNativeTypeOp,
{

Describe alternatives you've considered

Additional context

apache/datafusion#6003 as a use case where the selection vector would be beneficial.
apache/datafusion#5944 for a similar proposal.

[tustvold]

For primitives at least, I would expect a filter followed by the existing sum kernel to be very competitive, as it has been my experience that LLVM struggles to vectorise operations involving bitmasks.

We should definitely benchmark any new kernels against this "naive" approach

[tustvold]

I'm going to close this as a duplicate of #3620 to allow this to be discussed in a single location

[alamb]

label_issue.py automatically added labels {'arrow'} from #4393