Array take doesn't make fields nullable

[midnattsol]

Describe the bug

When calling arrow::compute::take on an Array with non-nullable fields and passing take indices that contain null values, the resulting Array contains null values. This is an invalid state.

To Reproduce

use arrow::array::Array;
use arrow::array::{Int32Array, StringArray, StructArray};
use arrow::compute::take;
use arrow::datatypes::{DataType, Field};
use std::sync::Arc;

fn main() {
    // Crear un StructArray con campos no anulables
    let field1 = Int32Array::from(vec![Some(1), Some(2), Some(3)]);
    let field2 = StringArray::from(vec![Some("a"), Some("b"), Some("c")]);
    let struct_array = StructArray::from(vec![
        (
            Arc::new(Field::new("field1", DataType::Int32, false)),
            Arc::new(field1) as Arc<dyn arrow::array::Array>,
        ),
        (
            Arc::new(Field::new("field2", DataType::Utf8, false)),
            Arc::new(field2) as Arc<dyn arrow::array::Array>,
        ),
    ]);

    // // Create an array of indices with null values
    let indices = Int32Array::from(vec![Some(0), None, Some(2)]);

    let field1_column = struct_array.column_by_name("field1").unwrap();
    let field1_result = take(field1_column, &indices, None).unwrap();
    let field1_result = field1_result.as_any().downcast_ref::<Int32Array>().unwrap();
    println!("Result field1: {:?}", field1_result);

    let field2_column = struct_array.column_by_name("field2").unwrap();
    let field2_result = take(field2_column, &indices, None).unwrap();
    let field2_result = field2_result
        .as_any()
        .downcast_ref::<StringArray>()
        .unwrap();
    println!("Result field2: {:?}", field2_result);
}

Output

Result field1: PrimitiveArray<Int32>
[
  1,
  null,
  3,
]
Result field2: StringArray
[
  "a",
  null,
  "c",
]

Expected behavior
Using take with null indices on Array with no-nullable values should return an error.

Additional context
This issue is related with this one #6727

[midnattsol]

Duplicated, it can be solved with a small change in the issue #6727