[FEATURE] Discussion of Flink Kubernetes native mode support

[Al-assad]

Hi, there 👋🏻

StreamX currently only supports YARN Application/Pre-Job mode for flink, but adding support for Flink Kubernetes native mode is essential.
Flink provides support for Kubernetes Native mode from 1.11 onwards, including K8s Native Session Mode(1.11+), K8s Native Application Mode(1.12+).

I have submitted a preview PR to provide support for the feature, see PR #221

Description of code adjustment

However, this PR is currently not perfect and requires at least the following adjustments to the current StreamX Flink task submission/job builder module:

1. Task submission interface method signature for the streamx-flink-submit module.

The method signatures of the flink task commit/stop interface (doSubmit/doStop) of FlinkSubmitTrait are currently designed entirely for YARN mode and lack the necessary adaptations for Native Mode (e.g. kubernetes.cluster-id, kubernetes.namespace, kubernetes.container.image, etc.)

2. Interface abstraction for file system operations

Currently StreamX's file system relies entirely on HDFS, which of course has little impact on K8s mode job submission itself, but the storage (checkpoint, savepoint, etc.) for Flink Jobs running on K8swill actually be more likely to use PVCs (such as NFS backend) or Object-based Storage from Cloud Providers (S3, OSS, COS, etc.) more often.

This is also necessary for subsequent k8s deployments of StreamX mainframe applications, as discussed in issue #192

Discussion points on docker dependencies

The Flink K8s appliction actually transfers the job jar build process to the docker image, and users need to solve this part of the image build themselves.

For an integration platform like Streamx, the solution may consist of 2 ways：

1. Pre-Built image, which is often used in the case of fixed business scenarios and fixed Maven dependencies, with the advantage that StreamX runtime does not need to couple Docker at all.

2. Build APP JAR Docker image in real time and push to container repository. This requires StreamX runtime to rely on Docker JNI and needs to handle the communication with the container repository used by K8s Cluster, which is more complicated but can support more scenarios.