Consistent way of managing config including secrets

[paulmelnikow]

Currently we have three ways of loading secrets:

1. In Heroku, other PaaS, and CI, from dynamic private/secret.json generated in a npm task at build time or runtime
2. In Docker, from dynamic private/secret.json via secret.tpl.json generated by the Dockerfile at build time
3. In the current / legacy production deploy, from checked-in private/secret.json generated in a deploy comment via the Makefile

I'd like to fold these three methods into a single method that covers on-premise, PaaS, and the current / legacy production deployment environment. To help solve #1848, this should not require a deploy commit.

See discussions: #2599 (comment) #2598 (comment)

Now that there is a config schema in lib/server.js, the server secrets could be folded into that. (However I want to make sure we do not accidentally leak credentials into log messages and error messages. So let's be careful that our config method doesn't do that.)

node-config is a great tool I've used in the past for cascading config. It lets you check in default configs which can be overridden by other checked-in configs for development, staging, production, or other environments (like self-hosting). You can create local config files which override those, and override anything else through environment variables. Here's a bit of explanation about how the cascade works.

Cascading config would replace the logic in lib/server-config.js, exposing a config object which could then be validated by Joi.

We could set NODE_CONFIG_ENV to values like shields-io-staging and shields-io-public which would then cause them to draw on additional config files which can be checked in and managed in this repo.

For the current / legacy production deployment, we still need a way to set NODE_CONFIG_ENV (#1806). The non-secret parts of the config can be checked into the main repo. For the secrets there are two options: (1) a checked-in local-shields-io-public.yml at deploy time, and (2) using additional environment variables.

There's a related proposal at #2577 (comment) about fetching the secrets from a secure token store for the legacy production deploy. However that proposal is adjacent to this one. That's about where the secrets are loaded at deploy time; this is about how they are loaded at runtime.

nconf looks like an alternative to node-config.

[paulmelnikow]

Closed via #2626.