improving how httpclients can be configured

[shawkins]

Description

The first commit is to fix #4472 - refined withRequestConfig so that a new client is not created. This removes the need / ambiguity or exposing the factory via the client - which is needed for #4471. It also makes withRequestConfig much lighter weight as it no longer creates an entirely new client. On the downside it requires a lot of wiring and a new Inteceptor method so that it can pick up the modified, rather than the default Config. The 6.0 changes allowed the maxConcurrentRequests and maxConcurrentRequestsPerHost to actually work - but as far as I can tell those did not work in 5.x. I vote for removing those methods from the RequestConfig entirely. I'll update the changes with docs based upon whatever we agree upon.

The second commit fixes #4471 - it adds a KubernetesClientBuilder.withHttpClientBuilderConsumer that can be used to configure the Builder that is created. We still need the KubernetesClientBuilder to take a Factory as TokenRefreshInterceptor expects to use the newBuilder() method to create a "fresh" client instance - that logic could be refactored of course, but that's too much for right now.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[manusa]

but as far as I can tell those did not work in 5.x. I vote for removing those methods from the RequestConfig entirely. I'll update the changes with docs based upon whatever we agree upon.

This seems fine, we can deprecate them and remove them in a subsequent release

[manusa]

I think I broke the feature while rebasing :( sorry :(
I hope you still have your local copy @shawkins

[shawkins]

Sure, let me see.

[shawkins]

This seems fine, we can deprecate them and remove them in a subsequent release

The pr currently has them removed - the rationale is that since they are probably used through the builder, a user unfortunately won't know they are deprecated unless they read the release notes.

[manusa]

This seems fine, we can deprecate them and remove them in a subsequent release

The pr currently has them removed - the rationale is that since they are probably used through the builder, a user unfortunately won't know they are deprecated unless they read the release notes.

that works too

[sonarqubecloud]

SonarCloud Quality Gate failed.   

1 Bug
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

41.2% Coverage
5.9% Duplication

[manusa]

LGTM, thx