Decoupling Event Sources and Dependent Resource and Related Issues

[csviri]

There are couple of issues that needs to be solved that are related to each other. This is an umbrella issue that tries to explain the problems, relationship between them, and set the goals and solution.

1. Decoupling Caches from Event Sources in API

Event Sources propagate the caches (both for informers and external resources), this is essential in a controller. Accessing the caches is now done through context.getSecondaryResource. However that we actually have a cache not on the event source and not some special additional own implementation of caching (what might be a case in the future), this API should not expose these internal. So we should remove the overloaded version, where the event source is referenced: #1240

2. Event Sources and Dependent Resources decoupling

Dependent resources now read the resource from the event source directly. This again makes an unnecessary coupling of the functionality provided by dependent resources with with event source. Would be much cleaner to access the cache just with the "standard" way, so with context.getSecondaryResource.

This would also help with the mocking and unit testing: #1355
Since users will be able to mock the context and do unit testing with dependent resources much easier.

Unfortunately there is one place where the dependent resource uses event source (so needs a direct reference to it now), is when filtering event propagation, so on our own changes we don't trigger reconciliation:

Might be bette to abstract away this in the future:
https://github.com/java-operator-sdk/java-operator-sdk/blob/9028970f278316c3236efd70819dae2dcddce576/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/dependent/kubernetes/KubernetesDependentResource.java#L230-L230

3. Handling Multiple Dependent Resources

see also: #1175

Currently without explicit labeling dependent resource are not able to handle multiple resources of the same type.
For this in the related PR, but also partially to nicer access caches (point 1.) the related PR introduces ResourceDiscriminator,
basically to filter target resources.

https://github.com/java-operator-sdk/java-operator-sdk/blob/9028970f278316c3236efd70819dae2dcddce576/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/reconciler/ResourceDiscriminator.java#L9-L14

Note that the goal here is that using this construct both int the Context and through it also the dependent resources, the users are able to select elegantly resources from caches. With this having multiple resources for the same resource type.
See samples:
https://github.com/java-operator-sdk/java-operator-sdk/blob/9028970f278316c3236efd70819dae2dcddce576/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/reconciler/ResourceDiscriminator.java

However now it provides access to low level API's for effective access of indexes, in event source, see sample:

https://github.com/java-operator-sdk/java-operator-sdk/blob/9028970f278316c3236efd70819dae2dcddce576/operator-framework/src/test/java/io/javaoperatorsdk/operator/sample/indexdiscriminator/IndexDiscriminator.java

TODO / Discuss

• have a nicer api for discriminator to access only indexes? So a generic indexing API ?
• now the configuration of standalone and managed event sources it little messy, discuss design that