Expose readiness/liveness probes

[khvn26]

Currently we expect orchestrators to execute a resource-heavy management command for each check. This might cause resource starvation on smaller clusters. In fact, we need to expose two health checks, preferably as HTTP endpoints:

• A simple liveness probe that means the task processor is running.
• A readiness probes that makes sure the database connections are healthy.

[rolodato]

+1 to separate liveness and readiness checks - see Flagsmith/flagsmith#5151 for an example.

I would also suggest making both checks be served over HTTP to avoid spawning new processes on the pods to run the health checks.

[khvn26]

With task-processor being a Django app installed on top of Core API, task-processor containers are in fact capable of using Core API's readiness and liveness probes introduced in

The following PRs need to be merged before we close this:

• feat: Remove unhealthy thread monitoring in favour of logging #25 removes the management command.
• feat: Switch existing task processor health checks to new liveness probe flagsmith#5161 redirects the management command call to the new liveness probe.