Extract configurable values from json config templates and docker-compose.yml to .env

[lognaturel]

Continuation of #389. The goals are for docker-compose.yml and the service config.json.template to very rarely be customized by users to minimize dirty files.

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

I tried the mail commit on a server using the default mail container (caribou) and using an external mail service (dev). In particular, I confirmed that it's acceptable to have empty username and password values.

I verified the extraction of the Sentry vars and the logic around the base URL by looking at the generated conf files in the containers.

I did not specifically verify the Node configuration but I think that can be visually inspected.

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

It's extending a pattern we've already established. I think it's a good balance of providing configurability in a flexible, secure way and not making dramatic changes to how things are done now.

I briefly looked into using env_file but I can't come up with a way to do defaults without resulting in ongoing file conflicts. The idea here is that the .conf.template files are responsible for the shape of the configuration and some number of almost-always static values, the docker-compose file is responsible for defaults for configurable values, and the .env file is responsible for deployment-specific configuration. It is ok for users to modify the template files if they have really special needs but then they're on their own for managing conflicts, etc.

I tried to use a name in the default for the no-reply email (e.g. ODK Central <no-reply@${DOMAIN}>) but couldn't get that to work. Tried no quotes, backslash-escaped < and >, single quotes, double quotes. It's currently nameless so this maintains the existing behavior.

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?

• There may be things that users customize but aren't pulled out into .env. That's annoying because they'll still have conflicts
• If any of the values from .env are incorrectly passed through docker-compose.yml and the starting scripts, then those values won't make it to the containers they're supposed to go to.

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

Yes, this will be addressed in getodk/docs#1577

Before submitting this PR, please make sure you have:

• verified that any code or assets from external sources are properly credited in comments or that everything is internally sourced