Problem was that if you enabled DynamicUser, it would remount
/ as read-only which wouldn't work, as we were using
the fact that / was read-write to set up all the mounts.

We work around this by actually making sure all the directories
that will be mount points exist apriori.  For things
for which mount points are dynamically generated on the fly,
we use TemporaryFileSystem (cache, log, state).

We also use TemporaryFileSystm for /nix/store. However,
we might not actually need it, as we know all the mount points
apriori.

TODO:

* See how we interact with APIVFS
* See if we can get rid of the TemporaryFileSystem for /nix/store,
because currently /nix/store _itself_ is read/write in the container (it
already was) and that's surely not something we want!

Make sure that /nix/store, /usr, /bin /var and friends are read-only
inside the container.

Especially for /nix/store this should defenitely be read-only as
otherwise we can break invariants (not good!).

/bin and /usr/bin being read-only also makes sense to me; however
it currently breaks some tests.  The test differentiated between
chroot-only mode and fullapivfs mode by testing whether it could
chown /bin.  We should test this in another way?

/var/{lib,cache,log} are also mount read only.  This means
the only way to create directories here is to use
StateDirectory/CacheDirectory/LogDirectory directives. This
is a tradeoff. Perhaps we should keep them read/write, as not
all our services use these options yet, and it might hinder
adoption of confinement. However when you enable confinement you
could as well just add these options.  We defenitely need to give
this some thought. Perhaps put it behind an option? I think
the others being read-only makes sense; but this one might
be a bit controversial