Fix parquet schema interpretation issue

[hyperbolic2346]

Description

There is a bug reading parquet files that have a specific encoding. The typical list is

<list-repetition> group <name> (LIST) {
  repeated group list {
    <element-repetition> <element-type> element;
  }
}

but it can also be

<list-repetition> group <name> (LIST) {
  repeated group list {
    repeated int32 name
  }
}

This second case was failing and this fixes that. The issue was the one_level_list was returning true for the name, which resulted in another nesting level. The fix is to only return true if the immediate parent is not a list.

closes #13237
closes #13239

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[PointKernel]

LGTM

Thanks for the fix

[mythrocks]

I've been trying to wrap my head around Parquet's handling for legacy LIST representations as well.

I think we are agreed on the first one:

<list-repetition> group <name> (LIST) {
  repeated group list {
    <element-repetition> <element-type> element;
  }
}

This conforms to the first section of the LogicalType spec:

It is required that the repeated group of elements is named list and that its element field is named element.

So this should be interpreted as LIST<element_type>.

Could I please have clarification on the second one?

<list-repetition> group <name> (LIST) {
  repeated group list {
    repeated int32 name
  }
}

The backward compatibility rules are:

1. If the repeated field is not a group, then its type is the element type and elements are required.
2. If the repeated field is a group with multiple fields, then its type is the element type and elements are required.
3. If the repeated field is a group with one field and is named either `array` or uses the `LIST`-annotated group's name with `_tuple` appended then the repeated type is the element type and elements are required.
4. Otherwise, the repeated field's type is the element type with the repeated field's repetition.

Wouldn't this case fall into the fourth category? In which case, should it not be interpreted as before the change? (i.e. LIST<LIST<INT32>>?)
Edit: I interpreted this incorrectly. This does indeed fall into the fourth category, which uses the element type, not the inner group's type. So this should really be LIST<INT32>.
I can verify this in Spark with the sample file used to test this change.

[mythrocks]

🚀 Thanks for the fix, @hyperbolic2346. LGTM!

[mythrocks]

I've re-kicked the failing test. Once it passes, if there aren't any objections, shall we merge this one?

[mythrocks]

/merge

[mythrocks]

Thank you for this fix, @hyperbolic2346!