[FLINK-39244][table] Support precision 0-9 for TO_TIMESTAMP_LTZ function

[raminqaf]

What is the purpose of the change

This pull request extends the TO_TIMESTAMP_LTZ(numeric, precision) function to support all precision values from 0 to 9, where precision specifies the unit of the epoch value as 10^(-precision) seconds. Previously only 0 (seconds) and 3 (milliseconds) were supported, which limited users working with higher-precision epoch values such as microseconds (6) or nanoseconds (9).

Brief change log

• Extended ToTimestampLtzTypeStrategy to read the precision literal from the second argument and return TIMESTAMP_LTZ(precision) with the correct precision. Validates precision is between 0 and 9.
• Added compile-time range validation for numeric literal arguments in ToTimestampLtzInputTypeStrategy, so out-of-range epoch values fail at validation time rather than silently returning null at runtime.
• Replaced per-precision switch cases in DateTimeUtils with a generic epochToTimestampData method using Math.pow for factor computation. Added inverse method toEpochValue(Instant, precision).
• Updated ValueLiteralExpression to serialize TIMESTAMP_LTZ literals using the precision from the DataType, preserving full precision. Previously it was hardcoded to precision 3 and threw for sub-millisecond values.
• Updated documentation in sql_functions.yml and sql_functions_zh.yml to reflect the expanded precision support.

Verifying this change

This change added tests and can be verified as follows:

• Added parameterized tests for all precisions 0-9 in ExpressionTest to verify TIMESTAMP_LTZ literal serialization round-trips correctly at every precision.
• Added type strategy unit tests in ToTimestampLtzTypeStrategyTest covering precision 0/3/6/9, out-of-range precision, and nullable/not-null input combinations.
• Added integration tests in TimeFunctionsITCase for precision 6 (microseconds) and precision 9 (nanoseconds) with numeric epoch values.
• Added serialization integration tests in LiteralExpressionsSerializationITCase for precisions 0, 3, 6, and 9.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changed class annotated with @Public(Evolving): no
• The serializers: no
• The runtime per-record code paths (performance sensitive): yes — DateTimeUtils.epochToTimestampData is called per-record but the change replaces a switch statement with Math.pow computations, which has negligible performance impact.
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? yes
• If yes, how is the feature documented? docs / JavaDocs

[flinkbot]

CI report:

• 4352f9e Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build