fix: BuildConfigs.instantiateBinary().fromFile() does not time out

[manusa]

Description

Fix eclipse-jkube/jkube#2024

BuildConfigs.instantiateBinary().fromFile() no longer times out based on the RequestConfig default read timeout value.

This PR addresses a bug present in OperationSupport where the overridden settings for RequestConfig in the OperationContext were ignored.

The PR fixes the problem with BuildConfig by overriding the requestTimeout value for the context RequestConfig whenever a withTimeout value is provided in the context. It will also default the RequestConfig requestTimeout initial timeout to 0 which will effectively disable the client-side timeout kill we perform at OperationSupport.waitForResult():

kubernetes-client/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/dsl/internal/OperationSupport.java

Lines 520 to 522 in d0ad014

	if (getRequestConfig().getRequestTimeout() > 0) {
	return future.get(getRequestConfig().getRequestTimeout() + ADDITIONAL_REQEUST_TIMEOUT, TimeUnit.MILLISECONDS);
	}

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

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication

[gsmet]

@Sgitario told me I hit that issue when deploying the Quarkus GitHub Bot to OpenShift so happy to see a fix, thanks!

[manusa]

@Sgitario told me I hit that issue when deploying the Quarkus GitHub Bot to OpenShift so happy to see a fix, thanks!

This one is especially critical for Quarkus and JKube, I'm sorry we didn't notice earlier. I'll try to release 6.5.0 next week and bump Quarkus dependency.

[shawkins]

@manusa with the new integration test it looks like the jdk execution hangs https://github.com/fabric8io/kubernetes-client/actions/runs/4310764866/jobs/7519523533#step:5:378 - unlike the other http clients the jdk client seems very strict (or incorrect) about the expectation of the expect continue response - it will wait indefinitely if it doesn't get an expected response. It currently does not get the expected response because of the go / kuberentes issue with case sensitivity to the header value. I'm wondering if this functionality will work for jdk if we disable its support for expect continue, if not we'll want to disable these tests for jdk.