How to control the runtime environment in which commands are run

As a followup of #174 (comment 432364), there's a general need in debusine to be able to control the environment in which we are performing the various tasks. We want to run lintian in various versions of Debian, autopkgtest/sbuild needs chroots/VM tailored to multiple versions of Debian, and autopkgtest (much like sbuild) has multiple options to make changes to the environment (add extra repository, use special environment variables, etc.).

The sbuild task relies on chroots created by ansible and the worker denies to take a work request if it doesn't have the appropriate chroot. It would be much better if the worker was able to dynamically create the required chroot or download it from the debusine server.

Also it would be nice if the user could describe the "runtime environment" in some generic way, and then just feed that pre-existing runtime environment to different tasks. You could create an environment with an extra APT repository, and use it to build packages, but also to run autopkgtest and lintian. The special options that we added to sbuild/autopkgtest to be able to add extra APT repositories become irrelevant since we can just build the correct environment and ask debusine to run stuff in there.

Here are the questions that we want to answer:

• do we agree that such an abstraction is desirable?
• if yes, what do we want to include in that abstraction?
• how does it relate to the future repository abstraction?
• how is that abstraction represented in the system? an artifact of category debian:runtime-environment? or a entirely database model?
• how and where would that abstraction be used to turn it into a chroot or podman/docker/VM image?
• what technology do we want to use by default for the basic "run a command in a specific environment" tasks (e.g. lintian)? podman? something else?