[FLINK-38253] Allow usage of vertx/jdk/jetty/okhttp clients in fabric8 in flink-kubernetes

[Frawless]

What is the purpose of the change

This PR add an option to use different HTTP client implementation in fabric8 used within flink-kubernetes module. It basically sync with operator repo, where this option was introduced few months ago as part of apache/flink-kubernetes-operator#881.

The default client implementation remains okhttp, but the change will allow usage of new profiles that switch used http client implementations to vertx, jdk, or jetty.

Brief change log

Enable to build flink-kubernetes with vertx, jdk, or jetty http clients implementations for fabric8.

Verifying this change

This change is already covered by existing tests, such as all tests related to flink-kubernetes module.

I also added new CI workflow that runs unit/ITs with all of the mentioned implementations and also smoke e2e test with minikube.

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

• Dependencies (does it add or upgrade a dependency): yes
• 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): no
• 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? no
• If yes, how is the feature documented? not applicable

[flinkbot]

CI report:

• a3f4206 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

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

[Frawless]

Here is GHA run from my fork - https://github.com/Frawless/flink/actions/runs/16989320117

[davidradl]

I am curious how long do all these new testing permutations add to the ci times?
Also in the spirit of FLINK-33901, should we implement these new CI tests in github actions rather than the Azure CI?

[Frawless]

In my fork it was 4 parallel jobs, around 25 minutes per each and it finished like 1h before current jobs for e2e tests that were running in parallel with these new ones. I basically followed the same approach as was implemented in operator repo as part of apache/flink-kubernetes-operator#881

Regarding Azure vs GHA, my understanding was that Flink community is aiming to move from Azure to GHA, that's the reason why I implemented it there. If we agree that Azure is a preferable way, I am happy to extend Azure pipelines. I understand this might need longer discussion so implementation in this PR can be used more like as a PoC.