Fix parquet read tests that fail on Databricks with date/time input [databricks]

[ttnghia]

Before #9617, reading parquet files fallback to CPU on LEGACY rebase mode only if the input contains date/time columns nested inside other columns. After PR 9617, reading parquet files now always fallback to CPU on LEGACY rebase mode if there is any date/time input at any nested level.

Since Databricks sets the rebase mode to LEGACY by default, some tests for parquet read now fail. This PR adds the explicit read config to fix them.

Closes #9636.

[ttnghia]

build

[ttnghia]

build

[jlowe]

After PR 9617, reading parquet files now always fallback to CPU on LEGACY rebase mode if there is any date/time input at any nested level.

Seems like #9617 is broken then and the proper fix is to revert it? This seems like a regression in functionality vs. what we supported before. Tests for date/timestamps at the top level of the schema were passing on Databricks before.

[ttnghia]

I think #9617 is correct (i.e., before it, there was a bug). Because if the read config is set to LEGACY, we must fallback to the CPU (after #9617), instead of just running on the GPU then throwing exception if the input needs rebase (before #9617).

[jlowe]

before it, there was a bug

It was not a bug but an intentional, calculated risk. In most cases, the query runs as expected, GPU accelerated with no crashes. Yes, sometimes it can crash, but the alternative in #9617 is that now all GPU Parquet reads on Databricks involving dates or timestamps are disabled by default. That will be very impactful for many users, and thus seems like #9617 should not have been committed.

[ttnghia]

Okay then I can revert the GPU tag logic in it.