[AMORO-3853] Support Java 17 build for Amoro

[xxubai]

Why are the changes needed?

Close #3853.

Amoro currently cannot reliably build and validate under JDK 17 beyond the Trino-specific path. Some build configuration still assumes older JDK behavior, and the mixed Flink module uses reflective access or non-public Flink/Iceberg internals that are fragile under the Java module system.

This PR adds experimental JDK 17 build support while keeping JDK 11 as the baseline, and updates CI to validate both JDK versions.

Brief change log

• Add a java17 Maven profile with the required compiler, surefire, and javadoc module opens/exports.
• Update dependency/build settings for JDK 17 compatibility, including cglib, slf4j, surefire configuration, Hudi compiler inheritance, Paimon surefire setup, and Trino toolchain matching.
• Extend core Hadoop 2 and Hadoop 3 CI matrices to run with both JDK 11 and JDK 17.
• Refactor mixed Flink read/write paths to avoid unsafe reflection and non-public API usage:
  • add KerberosAwareInputFormat;
  • replace Iceberg StreamingReaderOperator dependency with UnkeyedStreamingReaderOperator;
  • remove FlinkClassReflectionUtil;
  • build FlinkInputFormat directly from public table metadata;
  • use public Flink accessors where available.
• Update README to document JDK 11 and experimental JDK 17 build support.

How was this patch tested?

• Add some test cases that check the changes thoroughly including negative and positive cases if possible

  Existing mixed Flink tests were adjusted to cover the updated JDK 17-compatible read/write paths.

• Add screenshots for manual tests if appropriate

  Not applicable.

• Run test locally before making a pull request

  ./mvnw validate passed locally with Temurin JDK 17.0.17.

Documentation

• Does this pull request introduce a new feature? (yes / no)

  yes

• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

  README

[xxubai]

Could you please take some time to review this PR? This PR is a crucial prerequisite for upgrading Iceberg 1.11.0 and adapting to Iceberg v3. Thank you! cc @zhoujinsong @czy006 @klion26 @j1wonpark

[xxubai]

Additional review notes to help focus this PR:

• The most regression-sensitive Flink sink path is the Iceberg files committer creation. Please keep it on the authenticated overload, IcebergClassUtil.newIcebergFilesCommitter(..., mixedTable.io()), so committer callbacks still run through AuthenticatedFileIO#doAs in Kerberos deployments.
• When rebuilding Iceberg ScanContext without the previous private/reflection-based path, split locality should be preserved with the same public behavior: honor FlinkConfigOptions.TABLE_EXEC_ICEBERG_EXPOSE_SPLIT_LOCALITY_INFO, and otherwise rely on Hadoop block-location availability through Iceberg public Hadoop utility.
• For Hadoop3 Spark CI, JDK 17 should be treated as experimental coverage and only needs to run with Spark 3.5. Spark 3.3/3.4 remain covered by the JDK 11 matrix.

[klion26]

Thanks for the great contribution! I'll take a look at it this week.

[klion26]

Do we need to migrate to the new source api?

[xxubai]

UnkeyedStreamingReaderOperator is intentionally a minimal replacement for Iceberg's non-public StreamingReaderOperator, so that we can avoid depending on private Iceberg internals while preserving the existing FlinkInputFormat scan behavior and the Kerberos AuthenticatedFileIO#doAs wrapper.

[klion26]

Why do we need to change this,

[xxubai]

KerberosInvocationHandler currently proxies methods exposed through the proxied object's interfaces.

In practice, the invocation path goes through public interfaces such as OneInputStreamOperator and SourceFunction. As a result, these method invocations do not require method.setAccessible(true).

Keeping method.setAccessible(true) would introduce unnecessary deep-reflection behavior, which is exactly what this JDK17 compatibility change is trying to avoid.

[j1wonpark]

Built all modules on JDK 17, and ran the amoro-mixed-flink-common suite on both JDK 11 and 17 — identical results, no correctness issues found (the only failures are local Kafka testcontainer issues, unrelated to this PR).