[Iceberg]Support timestamp without timezone in time travel expressions

[hantangwangd]

Description

We have supported time travel query on Iceberg table in PR #21425, however currently we only support timestamp with timezone expressions in FOR TIMESTAMP AS OF as follows:

select * from tab1 FOR TIMESTAMP AS OF TIMESTAMP '2023-08-17 13:29:46.822 America/Los_Angeles';

In many scenarios, we do not want to explicitly indicate the time zone, but just default to using the time zone specified in the current session, since it's natural for users to execute queries based on the timestamp string in their own time zone.

This PR support timestamp without timezone in time travel expressions, so users can execute time travel query as follows:

select * from tab1 FOR TIMESTAMP AS OF TIMESTAMP '2023-08-17 13:29:46.822';

Timestamp without timezone will be parsed and rendered in the session time zone, it's consistent with data with type of TimestampType in Presto.

Motivation and Context

Support timestamp without timezone in time travel expressions

Impact

N/A

Test Plan

• Newly added test cases to show the behavior of timestamp without tz expressions under sessions with different time zone

Contributor checklist

• Please make sure your submission complies with our development, formatting, commit message, and attribution guidelines.
• 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 timestamp without timezone in time travel expressions :pr:`23714`

[steveburnett]

Just a nit suggesting a change in the link.

[steveburnett]

LGTM! (docs)

Pull updated branch, new local doc build, looks great!

[ZacBlanco]

This sentence is a little confusing to me. I think it's fair to specify that they are both valid -- but I think it would be good to explain what distinguishes them. Here's a suggestion, but feel free to modify:

Suggested change

	For example, `TIMESTAMP '2023-10-17 13:29:46.822 America/Los_Angeles'` and `TIMESTAMP '2023-10-17 13:29:46.822'` are all constant strings for the expression.
	For example, `TIMESTAMP '2023-10-17 13:29:46.822 America/Los_Angeles'` and `TIMESTAMP '2023-10-17 13:29:46.822'` are both valid timestamps. The first specifies the timestamp within the timezone `America/Los_Angeles`. The second will use the timestamp based on the user's session timezone..

[hantangwangd]

Thanks for your suggestion, modified! This change makes it more clear for readers to understand, please take a look when available.

[ZacBlanco]

Not a huge fan of the busy loop but I know we do this elsewhere, so I won't block on this but it wastes a lot of resources especially for concurrent tests.

[hantangwangd]

I see your point, but sometimes we do need to make sure that several consecutive actions happen in different milliseconds. I'd like to to make a detailed investigation into the time frame library later to see if there is a more suitable non busy loop waiting solution, and open for any better thoughts.