Context and Capabilities model.

[krisnova]

As we grow the feature set of Aurae one thing is being made more and more clear, which is:

The auraed runtime daemon will need to reason about the environment in which it is running.

For example under a specific set of conditions the daemon will assume it is running as a pid 1 host init system, and will potentially need to mount various filesystems, configure networking, manage syslog, and so on.

For example under another set of conditions the daemon will assume it is running as a pid1, but this time inside of a container (new cgroup namespace), and another set of assumptions and context becomes relevant.

As we look at the daemon init module, it is becoming evident that we will likely want to enable/disable various subsystems (gRPC services) based on the context in which we are running.

For example, if we are running as a true pid 1 we should check and see if virtualization is possible and only initialize the virtualization subsystem if relevant. If we are running as a container pid 1, we should likely only have the Pods service, and Cell service enabled.

Open Architecture Questions

How do we architect the code base in a "rusty" way such that we can easily plumb conditions/checks into the init module to determine the context in which we are running? How do we use these context checks to inform which subsystems to initialize? How do we "advertise" or "report" the available subsystems back to the user?