Deploy SecureDrop with libostree

[heartsucker]

Feature request

Description

We should use libostree to deploy SecureDrop instead of using Debian packages with heavy reliance on significant Ansible configuration.

Note: This somewhat depends on #1532 for us to be able to even build our own images in the first place. Or at the very least, #1532 is a significant step towards being able to implement libostree.

Deploying with libostree

FPF / SecureDrop's Side

1. The base of the SecureDrop system is installed via Ansible as it is currently
   a. This includes packages, configs that are the same across instances
2. The objects are pushed to the distribution server (or S3) by FPF

Admin's Side

1. The admin pulls the SecureDrop git repo as currently
2. The admin runs the configure script to generate a local .yml config
3. The admin runs Ansible against the servers that are bootstrapped with some basic OS (likely Ubuntu)
   a. This playbook is very minimal
   b. This playbook depends on Prevent admins from using ansible to clobber servers / configs #2964
   c. This playbook only installs libostree and points it toward the FPF object store, then pulls the version whose commit hash is in the signed part of the git repo. This makes the git tag effectively our signed manifest instead of the apt release file.

From the Servers' Sides

1. When the server boots, systemd is set up so that before network is started, there is a unit called securedrop-configure that does the following.
   a. Loads /var/lib/securedrop/config.yml
   b. Runs a minimal Ansible playbooks against localhost to generate the few customizable configs (e.g., sshd_config, torrc)
   c. The rest of the services boot
2. The FPF pre-baked image polls periodically for new images and installs them
3. /var/run/, /var/lib, and /tmp still are writable and persist across ostree pulls.

Additional Considerations

Because the underlying FS is read only (except where writes are explicitly allowed), something like cron-apt would not work. This (libostree) goes inline the idea we're pursing of no untested code/configs/dependencies in prod.

This means that every update to every package would require a full image rebuild. This means we'd have to push new images much more often to address security updates. This also means that we'd have to have a much better e2e CI story so that automated builds can kick off every time there's an update somewhere in the stack. This update is verified manually, a new build is finalized locally, then pushed to the libostree object store.

Further, the above automated builds would need to be reproducible since a CI build could happen at time X and the final build we sign could happen at time X+1 which might have an update to some dependency in that time. All dependencies and transitive dependencies would have to be nailed down in a lock file of some sort.

This is a heavy amount of load to put on FPF, but it will massively simplify the actual deployment from the end user's perspective.

User Stories

As an admin, I want my server deployment to depend on a series of Ansible tasks I execute as little as possible (because those seem to break often).

As a SecureDrop developer, I want more control over the state of the running SecureDrops.

[eloquence]

Closing this for now since we're not necessarily committed to this strategy, but we will evaluate in the context of #5517; cross-linking for reference there.