Use pillarenv/saltenv to remove branching logic in provisioning

[rocodes]

• [x] I have searched for duplicates or related issues

Description

Filing for discussion

Right now our provisioning logic copies everything needed for provisioning into one common Salt directory, and uses conditionals in .sls files to choose the right path(s) for provisioning, leading to lots of branching logic {% if d.environment == "staging" %} ... {% elif d.environment == "prod" %}. Part of why the provsioning is complex is because it's trying to deal with different build flavours/environments, and can't tell which one to use until orchestration/apply time.

I think we could use saltenv/pillarenv and simplify our lives:

• define separate pillars (data stores) for staging, dev, or prod data, but keep salt states shared across all environments so no Salt duplication
• at provisioning time, specifying the environment when invoking salt command (qubesctl state.apply pillarenv=dev) ** (use the pillarenv_from_saltenv configuration option for sanity)
• In each of dev, staging, or prod, we'd have the pillars (data) specific to the build environment, namely (securedrop-workstation.repo, sd-release-key.asc), meaning sd-default-config{.sls,.yml} wouldn't be needed.
• We could also simplify our conditional provisioning of systemd services (wip #1038) and be conditionally provisioned via the use of preset files that vary depending on build envrionment. (This could happen anyway: https://github.com/freedomofpress/securedrop-workstation/issues/1052)
• I think this structure will translate even when we move away from Salt. (ansible environments etc)

How will this impact SecureDrop/SecureDrop Workstation users?

• The more logic we remove from dom0 salt states, the faster provisioning is, but more importantly, the faster every updater run is

How would this affect the SecureDrop Workstation threat model?

• More reliance on systemd
• Maybe easier to reason about system state

[cfm]

I support this approach wholeheartedly. As you point out, @rocodes, it has precedent in how we parameterize securedrop's Ansible playbooks. It would be wonderful to be able to separate configuration from provisioning logic.