feat: ReconcileUtils for strongly consistent updates - alternative algorithm

[csviri]

• The PR adds utility that provides methods to update resources using comparable resource versions
• Integrates this utility to the core of the framework (thus simplifying ReconciliationDispatcher)
  • note that this introduces a change in the behavior for the UpdateControl.patchStatus (and others), since it won't trigger the reconiliation for the event in that update.
• Renames former ReconcilerUtils to ReconcilerUtilsInternal, this is breaking but that utils was never advertised for non-internal usage
• Includes also fixes for ControllerEventSource event filtering
• Improves TemporaryResourceCache so it explicitly supports non filtering updates

[csviri]

@shawkins I changed here the event filtering algorithm; one bit that bothered me with the one on next branch is the locking that is indirectly bound to an I/O operation:

java-operator-sdk/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/TemporaryResourceCache.java

Lines 106 to 109 in 589b7a6

	if (lock != null) {
	lock.lock(); // wait for the modification to finish
	lock.unlock(); // simply unlock as the event is guaranteed after the modification
	}

Although in normal case this would not cause to much of a delay in event processing since the event from our update will arrive just after the request is sent. However considering the case when some does an update on the same resource just when we starten our filtering update this might lock the thread for the full duration for the request processing. So I created an alternative implementation (first version, to be refined soon) with our good old friend event recording. Pls take a look if you have the bandwidth, and let me know what do you think. thank you!!

[shawkins]

However considering the case when some does an update on the same resource just when we starten our filtering update this might lock the thread for the full duration for the request processing.

That is correct. Until the update is complete, event processing is paused once you hit an event for the same resource. Part of the motivation was this allowed to keep much of the existing calling code structure.

So I created an alternative implementation (first version, to be refined soon) with our good old friend event recording. Pls take a look if you have the bandwidth, and let me know what do you think. thank you!!

There's a lot of changes here, so it may take a bit to fully review. Since we're really just trying to solve the case of the update event delivered prior to the completion of the update operation, things may be able to be simplified a bit. I put some ideas in #3109

Otherwise I think things look good. Having most of the handling localized to eventFilteringUpdateAndCacheResource will keep things more straight-forward.

[csviri]

@shawkins something went wrong with this force push I will revert it here if not objections, could you pls propose changes in you branch? thx

[shawkins]

@shawkins something went wrong with this force push I will revert it here if not objections, could you pls propose changes in you branch? thx

I'm sorry, I just noticed that I'm tracking the upstream branch for some reason.

[csviri]

This is not right. Note that it is used only if there is no explicit filtering

[shawkins]

You can remove that commit from this pr. We can discuss on #3114

[csviri]

np, just moved it back for now.