Adding Parquet footer metrics behind debug config flag

[mattahrens]

Contributes to #9265

[abellina]

readAndFilterFooter is being invoked, from lots of places. I see the following so far:

• On task thread: GpuParquetMultiFilePartitionReaderFactory.buildBaseColumnarReaderForCloud > filterBlocks > readAndFilterFooter. Your change is ok: task thread.

• On task thread: GpuParquetMultiFilePartitionReaderFatory.buildBaseColumnarReaderForCoalescing > filterBlocksForCoalescingReader:

  • If numFilesFilerParallel > 0: we are going to submit a CoalescingFilterRunner to a thread pool. CoalescingFilterRunner will then invoke filterBlocksforCoalescingReader in a thread that is not the task thread. Your change is not ok here, because then the footer fetch time is not task relative.
  • else, we call filterBlocksForCoalescingReader directly from the task thread. Your change is ok here.

• On task thread: GpuParquetPartitionReaderFactory.buildColumnarReader > buildBaseColumnarParquetReader > filterBlocks. Your change is also ok here.

Note that we have the metric FILTER_TIME. It is updated in GpuParquetMultiFilePartitionReaderFactory.buildBaseColumnarReaderForCoalescing, and GpuParquetPartitionReaderFactory.buildBaseColumnarParquetReader. These are measuring task relative time because they are in the task thread and are starting before we submit to the thread pool, and ending after we get all the futures resolved.

For the multi-floud cloud readers, we updated FILTER_TIME in MultiFileCloudPartitionReaderBase.next using a different approach. Here, we obtained a percentage of time that a thread (not the task thread) spent buffering vs filtering (getFilterTimePct and getBufferTimePct). We then multiplied that time times the amount of time that the task was blocked waiting for the threads to finish. The HostMemoryBuffersWithMetadaDataBase class has the logic on how we compute that. It seems that we would want to do something similar for footer fetch/filter time ColescingFilterRunner case.