[#1587] Adds connected worker info. to the healthcheck

[seanpreston]

Closes #1587

Code Changes

• Adds "workers": {...} to the healthcheck response to reflect connectivity of any workers connected to the Celery backend
• move the worker service back into the main compose file so that it's easier to spin things up
• add a -- worker posarg to the dev command that spins up the worker with the application

Steps to Confirm

• Run the server with nox -s dev
• Confirm no workers key is present at http://localhost:8080/health
• Set task_always_eager=false in celery.toml
• Run the server with nox -s dev -- worker
• Confirm workers key is present at http://localhost:8080/health and contains one result

Without workers configured

{"webserver":"healthy","version":"1.9.2+84.ge1dc3cb27.dirty","database":"healthy","cache":"healthy","workers_enabled":"False","workers":[]}

With workers configured and healthy

{"webserver":"healthy","version":"1.9.2+84.ge1dc3cb27.dirty","database":"healthy","cache":"healthy","workers_enabled":"True","workers":["celery@0729b9943a81"]}

With workers configured but not healthy (manually kill the worker container)

{"webserver":"healthy","version":"1.9.2+84.ge1dc3cb27.dirty","database":"healthy","cache":"healthy","workers_enabled":"True","workers":[]}

Pre-Merge Checklist

• All CI Pipelines Succeeded
• Documentation Updated:
  • documentation complete, or draft/outline provided (tag docs-team to complete/review on this branch)
  • documentation issue created (tag docs-team to complete issue separately)
• Issue Requirements are Met
• Relevant Follow-Up Issues Created
• Update CHANGELOG.md

Description Of Changes

Right now this solution will:

• return connected workers — unhealthy workers will not be shown in an unhealthy state, but omitted from results entirely.
  • The reason for this is that Fides can't know if a worker exists (let alone its health status) if it is not connected to the backend (Redis).
  • To obtain the health status of an individual worker, Individual workers can be pinged at /health for an accurate healthcheck of that container.
• return the standard .ping() response of {"ok": "pong"}. Alternatively there's a .stats() inspect method which could be used to show: pid of the worker on the container it's running on, uptime of the process, pool data, backend connection details — this seemed like overkill in the context of the other checks returning a simple "healthy".

[ThomasLaPiana]

@seanpreston please note that I made an additional change here! I updated the description and the steps to confirm so please double check my work too 🙏

[ThomasLaPiana]

@seanpreston woops, I also realized there's no test for this either

[ThomasLaPiana]

@seanpreston can you update the health endpoint tests for this so its more clear what to expect the responses to look like? (tbf I think there is a single one

Edit: nevermind I'm up, i'll update the test real quick

[ThomasLaPiana]

@seanpreston given the logic that unhealthy workers aren't shown, why show "ok"? I'm updating the code here but feel free to revert if you think it isn't more intuitive