There's quite a bit more we could do here, but this hits my basic usage
with vnets. Future work here would be things like ipv6 support or trying
to infer what a custom `interfaces` setting means.
I think these are the same concept, but with slightly different execution.
The main idea is to have a central base system that is shared (readonly) among
multiple jails. When this base system is updated, all the jails that reference
it immediately see the new system files.
This is implemented in iocage as a set of individual zfs mounts, one per
system directory. In Bastille, each system directory is symlinked into a
subdirectory of a single zfs mount.
My test plan here was to import an exported iocage basejail and verify that
its Bastille version has the right fstab and symlink changes:
```
Validating file: ssl_2021-11-19.zip...
File validation successful!
Importing 'ssl' from foreign compressed .zip archive.
Archive: ssl_2021-11-19.zip
extracting: ssl_2021-11-19
extracting: ssl_2021-11-19_root
Receiving ZFS data stream...
Generating jail.conf...
Updating symlinks...
ln: usr/src: Directory not empty
Warning: directory usr/src on imported jail was not empty and will not be updated by Bastille
Container 'ssl' imported successfully.
```
This property is not set by default on all iocage jails. By default, iocage assumes this value is 4. Confusingly, if you query this value from iocage while the jail is running, it will give a dynamically generated value. However, a jail must be stopped to be exported, so we can trust the value in config.json.
