Further configuration polish

[metacosm]

• refactor: DependentResourceManager now configures DependentResources
• refactor: remove DesiredSupplier since it makes things less readable

[sonarqubecloud]

SonarCloud Quality Gate failed.   

1 Bug
0 Vulnerabilities
1 Security Hotspot
23 Code Smells

29.4% Coverage
0.7% Duplication

[csviri]

• refactor: DependentResourceManager now configures DependentResources

@metacosm why coupling configuration abstraction with DependentResource resource? don't see gain for that. Especially since the base level contains these 2 objects:

Class<? extends DependentResource<R, P, ? extends DependentResourceConfiguration<R, P>>> getDependentResourceClass();

  Class<R> getResourceClass();

Where the resource class is already in the interface (see getResourceType), and and the getDependentResourceClass is the current class where we are putting this.

The other configs, could be just solved with an adaptor to a nicely polished config builder (will work on that on monday).
In addition to that the whole point of the controller was to not do this, in the first place, so to have the configuration service independent.

Just to be clear the main objection is put such configuration abstraction to DependentResource interface. This should not be forced.

• refactor: remove DesiredSupplier since it makes things less readable

The supplier was there so the user is not forced to create subclasses, this is something we can discuss. But it makes nice to share the context between the implementations. AFAIK this we defintelly loos with this, while the desired could be overriden also before.

[csviri]

refactor: remove DesiredSupplier since it makes things less readable

Actually this might not be that much problem, since if its standalone the reference to other resource could be passed to it. So basically same as the context of the supplier.