improve: filter only own updates for read-after-write-conistency

[csviri]

Signed-off-by: Attila Mészáros a_meszaros@apple.com

[csviri]

@metacosm @shawkins @xstefank
This should be the new implementation that is now aware of intermediate events. So only filters out events for controller own changes. The algorithm is I think even simpler than before. The idea is simple, we record the events during the update, and we check at the end if there was event that is not related to our changes; if no we don't propagate an event.
If yes, we propagate an Update events, that contains as resource from the first event as previous version, latest as the actual resource + some edge case with delete event. ( This is important because filters might relay on the changed resource).

This approach however would be bulletproof if we handle the re-list in the informer from the fabric8 pr above. Since in some (rather extreme) edge cases, if there is a re-list, event might be lost. So the idea would be (will create a separate PR) that, if we got notified that goind to be a re-list we flip a switch, and until the sync is finished we simply allow to pass (don't filter) any events. I think without that this is not even possible to do 100% correctly. (but maybe @shawkins has some ideas)

https://github.com/fabric8io/kubernetes-client/pull/7899/changes

So this is the correct way of doing, with "maximal precision", the good think is that it is actually relatively simple.
However something so be aware about.

1. We record the events related to that one resource. This in average case (like when there is an event from our modification or one from 3rd party) is 0-2 events, in some extreme edge cases might be much more, when there are very frequent update on the resource both from the controller and some 3rd party, this might be more - even that this is for a limited time - while our updates are finished.

2. Regarding time, we currently support multiple concurrent updates, and we finish the processing after all concurrent updates are finished. Theoretically if we have a many-to-one scenario to many primary resources reconciliations write one single resource, this could be long even could lead to "starvation" like situation so the update is not finished. First of all, in controller many-to-one is quite rate, we could already tell don't use this feature for such scenarion. But also I will iterate on this a bit and maybe have it time bound / or request number bound as failsafe, that will solve this issue.