feat: start Camunda as one application

[romansmirnov]

Description

With this Pull Request, a Single Application (containing Operate and Zeebe) can be started via a camunda.sh script.

• When starting the Single Application via the script, a user can define a profile (operate, zeebe, or gateway) to start only specific application parts. The profiles operate and zeebe are applied by default.
• Align the configurations between Operate and Zeebe
• Ensures that all health checks are included depending on which part of the application is started.
• Change: Now, the health check shows details to help understand which part of the application might not be up.
• Ensures that the existing standalone application can still be started as usual and behave as usual.

Related issues

related #17579

[github-actions]

Operate Test Results

798 tests  ±0   795 ✅ ±0   7m 20s ⏱️ - 1m 7s
132 suites ±0     3 💤 ±0 
132 files   ±0     0 ❌ ±0 

Results for commit 672dc9e. ± Comparison against base commit 6a0b84e.

♻️ This comment has been updated with latest results.

[houssain-barouni]

LGTM!
@romansmirnov are you planning to create a Dockerfile that starts CamundaStandalone?
I am also wondering how we will solve the liveness probe (Operate requires the Broker to start, but Kubernetes will not open the network to the Broker (to the single app service) as the liveness probe still return false as Operate is still not ready)

[romansmirnov]

are you planning to create a Dockerfile that starts CamundaStandalone?

As discussed, we will do this once Tasklist is part of the Single Application as well.

I am also wondering how we will solve the liveness probe (Operate requires the Broker to start, but Kubernetes will not open the network to the Broker (to the single app service) as the liveness probe still return false as Operate is still not ready)

It should be tackled in a separate issue. I think a way to achieve that would be to depend on the context to fetch that, i.e., if Zeebe is started as part of the application, it could be retrieved directly from Zeebe. Later, with the unified REST API, we could get this information by using the topology request. I think there are different options on how to achieve it.