[NU-1979] Scenario statuses refactor: scenario status and deployment statuses are decoupled

[arkadius]

Describe your changes

This refactor aimed to distinguish between scenario status and the status of scenario deployments.
Scenario status is the combination of local actions (deploy/cancel) and deployments visible on engine side.
Before the change both things were coupled together. DeploymentManager has returned the scenario status. After the change, DM returns only the status of deployments and the process of resolution this statuses to scenario status is done in the Designers core.

API changes:

• Changes in DeploymentManager interface
  • DeploymentManager has only getScenarioDeploymentsStatuses method (previous getProcessStates returning List[StatusDetails]).
  • Method DeploymentManager.resolve should be removed - this work is done by Designer itself
  • DeploymentManagerInconsistentStateHandlerMixIn mixin should be also removed
  • stateQueryForAllScenariosSupport was renamed to deploymentsStatusesQueryForAllScenariosSupport
  • Other changes:
    • StatusDetails was renamed to DeploymentStatusDetails
    • Fields: externalDeploymentId, externalDeploymentId, attributes, attributes were removed from StatusDetails

Other things that were done:

• Old ProcessState was renamed to ScenarioStatusDto
• The process of determining of visual related things was encapsulated into ScenarioStatusPresenter and is done close to Resources instead of in domain services
• ScenarioStateProvider was split into ScenarioStatusProvider and EngineSideDeploymentStatusesProvider
• Bofore the change, the process of reconciliation of deployment finished statuses was done ad-hoc during fetching the scenario status, on the DM side. Now it is done in the separated class ScenarioDeploymentReconciler which is invoked periodically

Checklist before merge

• Related issue ID is placed at the beginning of PR title in [brackets] (can be GH issue or Nu Jira issue)
• Code is cleaned from temporary changes and commented out lines
• Parts of the code that are not easy to understand are documented in the code
• Changes are covered by automated tests
• Showcase in dev-application.conf added to demonstrate the feature
• Documentation added or updated
• Added entry in Changelog.md describing the change from the perspective of a public distribution user
• Added MigrationGuide.md entry in the appropriate subcategory if introducing a breaking change
• Verify that PR will be squashed during merge

[github-actions]

created: #7567
⚠️ Be careful! Snapshot changes are not necessarily the cause of the error. Check the logs.

[jedrz]

Wouldn't it be better to introduce our own FlinkJobId, wrapping either a String or a UUID, instead of relying on a class from the Flink API? If I skimmed through the PR correctly, do we only need the string representation of the job ID?

[arkadius]

This Flink's JobId is quite stable value class. TBH IMO we should remove the whole flink client related code and use Flink's official client for rest API (RestClient/RestClusterClient).