Determine security requirements for automating kernel builds

Splitting from https://github.com/freedomofpress/securedrop/issues/6514

On a technical level, to build packages one needs a machine (currently a clean Qubes VM) that has Docker installed, and then:

1. run make securedrop-core-5.15, wait 2+ hours
2. run make securedrop-workstation-5.15, wait 2+ hours
3. upload the build logs to the build-logs repo
4. sign and upload the source tarballs to S3
5. copy and upload the debs to apt-test, to kick off kernel testing

Currently these steps are done manually, on maintainer laptops. This seems ripe for automation, especially because it's a slow process.

One important note is that these builds are currently not reproducible (see #3).

So if we were to automate this process, what are the requirements for the build host? Would we be OK if:

1. it was entirely run on a CircleCI pipeline (or other cloud CI provider, e.g. CodeFresh)?
2. it was entirely run on a DO droplet we/infra controls?
3. it was entirely run on a physical machine under FPF control (e.g. in NYO)?
4. status quo, entirely run on a maintainer laptop

Pinging @l3th3 & @lsd-cat for security input

Start with the make securedrop-core-5.15 and make securedrop-workstation-5.15 entry points and review the current build-log, S3 signing, and apt-test upload steps. Compare the CircleCI or other cloud, controlled DigitalOcean, FPF physical-machine, and maintainer-laptop options, then document agreed security requirements for the build host.