Fix reading partition value columns larger than cudf column size limit

[parthosa]

Fixes #9110.

This PR fixes the issue when readers create partition value column that exceeds the cudf column size limit. This is fixed by checking size and creating multiple batches.

Tasks:

• Convert existing methods in MultiFileReaderUtils to an Iterator-based API.
• Update next() and hasNext() methods in GpuColumnarBatchWithPartitionValuesIterator.
• Implement logic to split partRows and partValues into partitions less than cuDF limit.
• Modify the code to split input of ColumnarBatch using the above partitions.
• Implement similar partitioning logic for the case with single partition values.
• Unify the structure for processing both the Single Partition Value and Multiple Partition Value cases.
• Remove redundant separate processing for the Single Partition Value case.
• Create a case class and iterator with pending queue to defer the merging of partition values until they are required.
• Ensure usage of reference counts, memory leaks and improve logic for splitting.
• Make cudf column size configurable and add unit tests.
• Add the retry framework
• Add unit tests in pyspark

Related Issue:

• [FEA] Optimize configuration handling in BatchWithPartitionData #9467

Performance Metrics:

Details:

• Workload Information -
  • Application: Basic Spark App that writes columns with variable-length strings as Parquet and reads it.
  • Spark Version: 3.1.1
  • Spark RAPIDS Version: 23.08
  • GPU: RTX A5000
• cuDF Column Limit: 2GB
• Size of ColumnVector = Num Rows * Size of Column Value

# Partition Cols	# Rows (million)	Largest Column Value (bytes)	Largest Column Vector (GB)	CPU Time (sec)	GPU Time (sec) (23.08)	GPU Time (sec) (current branch)	Speed Up (CPU/GPU current branch)
1	100	150	14.0	132.0	cuDF error	7.5	17.6
2	100	150	14.0	125.0	cuDF error	8.0	15.6
3	100	150	14.0	122.0	cuDF error	8.0	15.3
2	100	75	7.0	72.0	cuDF error	4.1	17.6
2	100	15	1.4	37.0	2.0	2.0	18.5
1	10	150	1.4	8.2	1.7	1.7	4.8

[tgravescs]

got most of the way through it, most of comments are just on better documentation, some of where I left it lacking

[parthosa]

This looks good overall, but it's still draft. Does it need to be?

It would be good to get some other eyes on this. @tgravescs @razajafri would you mind doing another round of review to see if I missed things?

Thank You @jlowe for the reviews. The implementation looks in a good shape. Removing the PR from draft status.

[razajafri]

I haven't gone over the whole thing, will do another pass later

[tgravescs]

need to look at a couple more functions here are comments so far

[tgravescs]

Looks good, other then adding a couple more tests

[tgravescs]

build

[jlowe]

build