[BUG] libcudf chunked Parquet reader hangs when loading Parquet with older array encoding

[jlowe]

Describe the bug
Potentially relates to #13237. Using the same Parquet test file from #13237, using the chunked Parquet reader to load the file will hang from the caller's perspective, never returning and consuming 100% of a CPU core.

Steps/Code to reproduce bug
Using the same test file from #13237, the following C++ program will reproduce the hang.

#include <iostream>

#include <cudf/io/parquet.hpp>
#include <cudf/lists/lists_column_view.hpp>
#include <cudf/types.hpp>

int main(int argc, char** argv) {
  std::cerr << "Creating reader" << std::endl;
  auto reader = cudf::io::chunked_parquet_reader(1L << 31, 
    cudf::io::parquet_reader_options::builder(cudf::io::source_info("pq891392009.parquet")));
  while (reader.has_next()) {
    std::cerr << "Reading batch" << std::endl;
    auto chunk = reader.read_chunk();
  }
  std::cerr << "Done reading" << std::endl;
  return 0;
}

Expected behavior
libcudf calls should not hang/crash on valid inputs.

[vuule]

I ran this test locally. Surprisingly, it actually completes after a few minutes. Fails with a bad_alloc exception.

[vuule]

Some more info:
The reader get stuck in this loop
https://github.com/rapidsai/cudf/blob/branch-23.06/cpp/src/io/parquet/reader_impl_preprocess.cu#L1080
in find_splits.
cur_row_count stays at zero while the num_rows is one, so it never exist the loop.
The bad_alloc is thrown because the loop keeps adding empty splits to, well, splits.

FWIW, we could detect that we're creating empty splits and throw instead of hanging until the heap is full.

CC @nvdbaranec who might better understand what is going wrong in the reader here.

[nvdbaranec]

This appears to be a misinterpretation of the schema due to an overzealous is_one_level_list() check. @hyperbolic2346 is looking at a fix.