Make internal configuration variables readonly to prevent users from overwriting them

[mishaschwartz]

Originally discussed in #647 (comment)

Should we make variables introduced in various default.env files that are meant for internal use only and should not be overwritten in a local environment file readonly?

Right now we handle this by not advertising these variables in env.local.example and don't refer to them in the user facing documentation (or explicitly mention that they should not be overwritten).

Some things to consider:

• is there ever a use-case for allowing users to overwrite these variables when they really know what they're doing?
• is it better to introduce a mechanism to warn the user if they're overwriting an internal variable instead?

For example, here are some variables that are for internal use only:

• COMPOSE_DIR
• ALL_CONF_DIRS
• BIRDHOUSE_ALLOW_UNSECURE_HTTP (in proxy)
• BIRDHOUSE_AUTODEPLOY_EXTRA_REPOS_AS_DOCKER_VOLUMES (in scheduler-job-autodeploy)
• GEOSERVER_SKIP_AUTH_PROXY_INCLUDE (in geoserver)

[tlvu]

Not sure we need that much heavy holding of the users. Like Python, we can use convention to signal an internal class variable so anyone using these can be broken at any time because API stability is not guarantied but Python do not block them. I actually like this flexibility rather that the Java style heavy holding.

Maybe documentations and warnings are good enough?

[tlvu]

• is there ever a use-case for allowing users to overwrite these variables when they really know what they're doing?

I override BIRDHOUSE_DEFAULT_CONF_DIRS to remove cowbird for our production.

Maybe in the default.env where they are introduced, create a section called internal and moved them there to indicate clearly the intention.