Use pre-built images

[lognaturel]

Closes #677

There's an ordering problem that I can't quite wrap my brain around. Let's say we want to tag v2024.2.0. That means we want to produce central-service with version v2024.2.0 and central-nginx with version v2024.2.0 AND we want to use those tags in the Docker compose file. So far the only process I can think of is to put in a commit that bumps the versions in Docker compose that will fail CI, tag (which will build the images), then run CircleCI again to actually test with the new images

This would be slightly less bad if we could guarantee that the Circle CI tasks ran after the image building. I think to do that we might need to move those tasks to Github?

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

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

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?

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

Before submitting this PR, please make sure you have:

• [x] 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

[tobiasmcnulty]

This isn't a direct answer per se, but I wonder if using an environment variable to define the tag (a la the compose interpolation docs) might help work around the ordering problem? You could for example use a different TAG on CI (latest?), but still include a common .env with the current version. Users desiring more customization could even copy/create their own .env and update the version by hand when they're ready to upgrade. Anyways, perhaps there a solution in there somewhere!