fix #4516: adding a blocking delete operation

[shawkins]

Description

Fixes #4516 with the ability to make delete a blocking operation.

The context changes are due to elevating timeout to the base context. To avoid multiple inheritance issues with Timeoutable it was converted to non-generic.

This option turns out to be a lot simpler than adding the force option to serverSideApply and replace - as all of the delete options (timeout, grace period, propagation) are needed for those contexts as well. And we just introduced a NonDeletingOperation interface which further complicates what could be common api point for specifying delete options.

The blocking delete is similar to what exists in the kubectl client when --wait is used as a parameter (delete, apply, replace). The returned statusdetails are used to determine the set of uids that you're tracking. Once none of those exist, you'll consider things deleted. A corner case is the possibility of incomplete statusdetails - that was noted in an old issue, but I'm not sure that it is still relevant and kubectl doesn't consider that case either.

This simplifies the workaround to just two calls:
op.withTimeout(10, TimeUnit.SECONDS).delete();
op.create();

This is also applicable to #3246 and similar issues.

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

[shawkins]

Updated with a changelog and rebased to master.

One change from the previous commit is that the blocking method was generalized so that it would work for list contexts to be applied in parallel, rather than serially.

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

19.4% Coverage
9.7% Duplication