Closes #577

* Original Comment *

Includes

• Correctly export the WORKER_COUNT variable in start-odk.sh, otherwise the value is not respected (see screenshots).
  • This is because pm2.config.js uses process.env.WORKER_COUNT, but the variable is only available in the bash shell, not the pm2 command (it needs to be exported for that).
• Fixed the determination of the available memory:
  • Currently the vmstat command gets the total available memory on the host system.
  • To get the available memory from either the host machine OR a restricted container in docker compose / Kubernetes, we need to inspect the cgroup.
• Added an optional for environment variable WORKER_COUNT for the backend service.
  • If this value is provided, it overrides the automatically generated value for WORKER_COUNT.
  • Added the empty variable to .env.template so users know it's an option.
  • The rationale for adding this is twofold:
    • During development it's good to be able to specify 1 worker, even on a machine with large memory.
    • If running in Kubernetes, it is generally not good practice to spawn multiple workers per pod. Ideally 1 process/worker per pod allows for easier load management, autoscaling, etc.
• Minor pedantic bash syntax fix: moved a then to the same line as if (in line with shellcheck and bashate linter recommendations).

Screenshots

Before: 4 workers determined, but only one runs

Log:

System info:

After: 4 workers determined, 4 workers run

Log:

System info:

What has been done to verify that this works as intended?

• Tests inside docker containers running on a Debian Bookworm host.
• This has not been tested via Kubernetes, but I see no reason why the underlying approach would not work.
• Also not tested on Docker Desktop or similar, but as they rely on emulation of a Linux VM, this should also work fine.

Why is this the best possible solution? Were any other approaches considered?

• This is the most straightforward solution to determine the memory restrictions from a cgroup.
• The official nginx image has a best practice approach that is quite convoluted, as it also involves determining other metrics.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

• This will not affect users running on systems with memory ~1GB memory.
• However, as it fixes the worker allocation, it will affect users with >1GB memory.
• Users may find that ODK Central takes more memory to run that it did previously, due to correctly spawning 4 processes.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

• It probably does require a docs update. I can make a PR.
• It would be useful to document the WORKER_COUNT environment variable is available.

Before submitting this PR, please make sure you have:

• branched off and targeted the next branch OR only changed documentation/infrastructure (master is stable and used in production)
• verified that any code or assets from external sources are properly credited in comments or that everything is internally sourced

* Updated Comment *

• Decided not to go ahead with WORKER_COUNT env var configuration, as a better approach is running one process per container.
• Container replicas can be configured via docker compose instead.
• This PR includes the total memory check via container cgroup, which should work in containers run both via Docker and Kubernetes.