Refactor: stream, deployment, config and pipeline

[ChrisRousey]

This PR refactors all the top level resources in datacater.

Refactors include:

• Moving all non-http methods from the endpoint classes to respective utility classes
  • pipeline resources in pipeline utility, stream resources in stream utility, etc.
• adding static config classes where not already existant
• removing "magic variables" to the static config classes
• refining some logging messages
• adding logging statements where I saw fit
• added a logger utility class for generic logger methods

Please feel free to make more suggestions.

[ChrisRousey]

Some of these utilities contain functionality that is also needed in DataCater EE. I am wondering whether it is feasible and would make sense to outsource such functionality into an own utility project, similar to what we did with the SerDe classes, such that we could include the shared functionality in both the open core and ee and effectively get rid of duplicated code.

@flippingbits do you have any examples of which utility methods could be shared off the to of you head so i can look further into this? Otherwise i'll have a look myself. In general I think this is a good idea. I'd have to test how smoothly we could migrate mutiny worker methods like StreamUtilities.getStreamFromDeployment() since they are entity dependant. We might also lose some sonarqube analysis metrics for the utilities, stuff like test coverage might not work correctly since, my guess is, we'd have to implement the tests in the main repo? But those are just guesses i'd have to confirm by testing this first.

[HknLof]

Just to jump in with another comment :D. From a Java Quarkus perspective, I do believe, that these would have to be externalized into Quarkus extensions or published as JARs.

[flippingbits]

@flippingbits do you have any examples of which utility methods could be shared off the to of you head so i can look further into this? Otherwise i'll have a look myself.

Yes, ConfigUtilities or StreamUtilities are examples of functionality that might be needed in EE. However, I would suggest to wait with outsourcing these classes for now, since we currently discuss other ways for a more efficient integration of the open core and EE. If it stays relevant, we could address it in a separate PR.

[sonarcloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
3 Code Smells

62.0% Coverage
0.0% Duplication