Move to Vert.x HTTP Client

[gastaldi]

Okhttp is no longer a single JAR and 4.x brings transitive dependencies (the kotlin-stdlib which is 1.5Mb).

There is a discussion about adopting Vert.x as the HTTP client here: quarkusio/quarkus#14662

Fixing this issue needs to also fix the problem reported in #2632

[jorsol]

Ideally, (but this might bring its own challenges) is to be agnostic of the HTTP Client, and make it pluggable, if users want to use Apache HttpClient 5, or OkHttp 4, or Vert.x HTTP Client, or what I consider a nice zero-dependency: Java 11 HttpClient, would be great, this way Kubernetes-Client will not force a particular dependency.

And yes, this is probably a more invasive change and is subject to more challenges that just stick to one dependency.

[gastaldi]

@jorsol I think that's also possible, considering an abstraction layer is introduced in the HTTP operations part.

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[shawkins]

Julien Viet provided an outline of a client support at shawkins/httpclient#1

There is still a fair amount of work to be done.

[shawkins]

@metacosm @vietj @manusa I've picked this up again at https://github.com/fabric8io/kubernetes-client/tree/vertx-client

There are plenty of unsupported things and todos left. I'll take another couple of passes over it to see if I can get the consume and interceptor logic roughed in - then reach out for anything that isn't easy to move forward.

It's not yet used, but later I'm guessing we'll need to use the abstract builder to support creating derived clients - the only really tricky thing there is the modification of the interceptors that we do for the openshift logic. It switches to specific token interceptor, or removes itself when making the refresh call.