[Iceberg]Support bucket transform for TimeType

[hantangwangd]

Description

In the Iceberg specification, columns of type TimeType support being specified bucket transforms. This PR support bucket transform for columns of type TimeType in presto.

Motivation and Context

Support as many types as possible for partition transforms according to Iceberg specification.

Impact

We can now use bucket transform on TimeType columns in Iceberg table.

Test Plan

• Newly added test case for testing the bucket transform set and used on TimeType columns of the Iceberg table.

Contributor checklist

• Please make sure your submission complies with our contributing guide, in particular code style and commit standards.
• PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
• Documented new properties (with its default value), SQL syntax, functions, or other functionality.
• If release notes are required, they follow the release notes guidelines.
• Adequate tests were added if applicable.
• CI passed.

Release Notes

== RELEASE NOTES ==

Iceberg Connector Changes
* Support bucket transform for columns of type `TimeType` in Iceberg table 

[steveburnett]

LGTM! (docs)

Pull branch, local doc build. Thanks!

[steveburnett]

Thanks for the release note entry! Minor nits:

== RELEASE NOTES ==

Iceberg Connector Changes
* Add support for bucket transform for columns of type ``TimeType`` in Iceberg tables.

[ZacBlanco]

I have one question

[ZacBlanco]

Just to confirm my understanding, we need to do this MILLISECONDS.toMicros here because the bucketing needs to be compatible with the bucketing of other systems? Is ther anything else stopping us from just doing bucketHash directly on the TIME.getLong(...)?

[hantangwangd]

To be compatible with the bucketing of other systems is one of the reason, but the more important reason is to be compatible with Iceberg's file planning with filter. When we query the partitioned table with a filter on column of type TimeType as follows:

select * from test_bucket_transform_on_time where a = time '01:02:03.123';

We will actually first use the predicate a = time '01:02:03.123' to execute Iceberg's file planning. Iceberg will use this time value internally to calculate partition values, and then scan some specific partitions, if the calculated partition value is not compatible, we won't find the corresponding data. So we have to make sure that the calculation of partition value is exactly the same as Iceberg lib, that is, use the micro seconds value to calculate the partition value.

So if we doing bucketHash directly on the TIME.getLong(...), we will find that the example query above get an empty result.

[ZacBlanco]

This was roughly my thinking. Thanks for confirming