read-cache-after-write consistency and event filtering for deletes

See also parent issue.

This might be a bit problematic, for resource without finalizer:

If the resource does not implement a finalizer, we could just record the UID of the resource and filter out events until we receive the delete event, that removes the cached resource ID.

The issue is with the resources with a finalizer, there we could define this like:

1. Filter just the event that was caused by the delete operation (in this case, it just adds the deletion timestamp), and process subsequent events. By definition, only operations should happen afterwards, and that includes finalizer removals, but that is not enforced on the API level. Note that implementation-wise, this is an issue since the delete operation does not return the new resource nor it's version.

2. We could filter out all the subsequent events until we receive a delete event. - But this might be too opionated, and especially if the controller would be restarted, users might see the resources again (although still marked for deletion). So probably not the right thing to do.

Notes:

• optimistic locking does not seems to work for deletes either

Beginne damit, die Read-Cache- und Ereignisfilterpfade für Löschvorgänge im Java Operator SDK zu lokalisieren, und prüfe anschließend das übergeordnete Issue auf das vorgesehene Verhalten. Vergleiche Ressourcen mit und ohne Finalizer sowie den Hinweis zum optimistischen Sperren; dieses Issue ist erst abgeschlossen, wenn die Richtlinie zur Filterung von Löschereignissen festgelegt und konsistent implementiert wurde.