explain rock-ons-root snapshots

[phillxnet]

Thanks to knucklehead101, mrseth1, glenngould, MvL, and anborn in the following forum threads for highlighting this issue. Since docker (Rockons) use snapshots to manage image layers their deletion will break installed Rock-ons. An explanation of their purpose and use will help to clarify their appearance in the Rock-ons-root share.

This explanation could be placed in the following doc section:
http://rockstor.com/docs/docker-based-rock-ons/overview.html#rockons-root

Referenced forum threads:
https://forum.rockstor.com/t/rock-ons-snapshot-removal/637
https://forum.rockstor.com/t/deleting-snapshots-breaks-rock-ons/2431
https://forum.rockstor.com/t/what-is-the-logic-of-rockstor-if-there-are-no-scheduled-snapshots/2928
https://forum.rockstor.com/t/solved-headphones-rock-on/3034
https://forum.rockstor.com/t/some-rock-ons-not-reachable-after-creating-new-rock-on-share-and-new-installation-of-rock-ons/8029

Possible background docker reference:
https://docs.docker.com/engine/userguide/storagedriver/btrfs-driver/

[phillxnet]

From the upstream docker link (btrfs-driver) above we have, in subsection: https://docs.docker.com/storage/storagedriver/btrfs-driver/#image-and-container-layers-on-disk

Only the base layer of an image is stored as a true subvolume. All the other layers are stored as snapshots, which only contain the differences introduced in that layer.

Or the possibly better overview of:

Docker's btrfs storage driver stores every image layer and container in its own Btrfs subvolume or snapshot. The base layer of an image is stored as a subvolume whereas child image layers and containers are stored as snapshots.

We should also add, by way of this issues resolution, a note on how we configure docker's btrfs driver to use the Rock-ons-root designated Share (btrfs subvolume). I.e. a mention of our config override for docker.