Upgrade Flink version to 1.20

[weiqingy]

Is your feature request related to a problem? Please describe.
Currently, Apache Auron depends on an older version of Apache Flink. As Flink 1.20 introduces upstream bug fixes, a bridge to 2.x, performance improvements, and newer API features, staying on an older version prevents us from leveraging these enhancements and creates potential compatibility issues for users running modern Flink environments.

Describe the solution you'd like
Upgrade the Flink dependency across the project to version 1.20.0 (or the latest 1.20.x line). This task should include:

• Bumping the Flink version in pom.xml / build files.
• Addressing any breaking API changes or deprecations introduced between our current version and 1.20.
• Verifying that all existing test suites and CI pipelines pass.

Describe alternatives you've considered
Staying on the current Flink version. However, this increases technical debt over time and isolates the Auron engine from the latest Flink ecosystem updates.

Additional context
Keeping dependencies up to date will also ensure better API compatibility as we work on deeper engine integrations, such as the ongoing work in #1851 (Introduce Arrow to Flink RowData).

[Tartarus0zm]

@weiqingy Thank you very much for your suggestion.
Flink on Auron is based on Flink 1.18 and involves the following considerations:

• Among the companies I know of, the Flink versions used in production are typically quite low; 1.17 and 1.18 are already considered relatively new versions.
• Currently, 1.18 is the version we use for development and validation. Flink on Auron has not been officially released yet. Once Flink on Auron is officially released, we will need multi-version support (e.g., 1.17, 1.18, 1.19, 1.20, and even 2.x) to facilitate broader adoption in production environments.

Following the official release of Flink on Auron, users can specify the Flink version via the compilation command, just as they would specify the Spark version.

[weiqingy]

Thanks @Tartarus0zm, that makes sense. Starting with 1.18 as the development baseline and adding multi-version shims after the initial release is a clean approach. I'll continue targeting 1.18 for my work on #1851.