Enable ability to store secrets separately from config.json

Current Situation

This request revisits a discussion from #1951.

Many accessory and platform plugins require logging in to a third-party API, which often means storing credentials inside config.json. This means that config.json must be treated with extra caution as it now contains secrets. For example, this precludes checking the config file into a source control system. Further, some secrets such as JWTs are very long, which can make the config.json file look unwieldy for hand-editing.

The official documentation even recommends pasting the config.json file into jsonlint.com to help validate the JSON structure and help people less familiar with the format troubleshoot syntax errors. While well-meaning, please don’t encourage users to paste secrets into an untrusted service!

Proposed Change

Instead of placing secrets in the config file directly, they would be stored in a .env file or environment variables. At config load time, instance of variable names prefixed with a “${” and ending in “}” would be replaced with the value. This style of replacement is pretty common, for example in docker compose files. The config file should still be syntactically valid JSON prior to replacement, so replacement variables will need to still be inside valid string values. To prevent breaking existing config.json files that may have what looks like embedded replacement variables, the replacement behavior will be opt-in via a boolean value at the root of the config file. Perhaps this setting can default to true for all new files.

Example: (before replacement)

{
  "replaceVariables": true,
  "bridge": { ... },
  "platforms": [
    {
      "token": "${PET_SAFE_API_TOKEN}",
      "platform": "PetSafeSmartFeed"
    }
  ]
}

(after replacement)

{
  "replaceVariables": true,
  "bridge": { ... },
  "platforms": [
    {
      "token": "eyJ ... (some long JWT)",
      "platform": "PetSafeSmartFeed"
    }
  ]
}

Not in scope for this initial work would be to add a UI for setting these secrets and/or previewing the config with replacements made. However, a future endeavor could be to add such a UI to the excellent oznu/homebridge-config-ui-x plugin.

Additional Context

I’m prepared to take a swing at implementing this, but wanted to give the core maintainers a chance to opine before I drop a pull request out of the blue, as well as hopefully mention any possible gotchas.