Run tests Docker in Docker (#261)

* Try running tests in Docker

* Spawn new container for each test

* Store test artifacts outside of mount

* When requested, build up to date image in test script

* sudo is unneccessary in containerized test env

* Skip azure test

* Backdate fixture file in JSON database

* Pin versions for azure tools

* Mount temp volume for /var/lib/docker to prevent dangling ones created by VOLUME instruction

* Fail backdating tests with message

* Add some documentation on test setup

* Cache images

* Run compose stacks with shortened default timeout

test/README.md

@@ -0,0 +1,70 @@
+# Integration Tests
+
+## Running tests
+
+The main entry point for running tests is the `./test.sh` script.
+It can be used to run the entire test suite, or just a single test case.
+
+### Run all tests
+
+```sh
+./test.sh
+```
+
+### Run a single test case
+
+```sh
+./test.sh <directory-name>
+```
+
+### Configuring a test run
+
+In addition to the match pattern, which can be given as the first positional argument, certain behavior can be changed by setting environment variables:
+
+#### `BUILD_IMAGE`
+
+When set, the test script will build an up-to-date `docker-volume-backup` image from the current state of your source tree, and run the tests against it.
+
+```sh
+BUILD_IMAGE=1 ./test.sh
+```
+
+The default behavior is not to build an image, and instead look for a version on your host system.
+
+#### `IMAGE_TAG`
+
+Setting this value lets you run tests against different existing images, so you can compare behavior:
+
+```sh
+IMAGE_TAG=v2.30.0 ./test.sh
+```
+
+#### `NO_IMAGE_CACHE`
+
+When set, images from remote registries will not be cached and shared between sandbox containers.
+
+```sh
+NO_IMAGE_CACHE=1 ./test.sh
+```
+
+By default, two local images are created that persist the image data and provide it to containers at runtime.
+
+## Understanding the test setup
+
+The test setup runs each test case in an isolated Docker container, which itself is running an otherwise unused Docker daemon.
+This means, tests can rely on noone else using that daemon, making expectations about the number of running containers and so forth.
+As the sandbox container is also expected to be torn down post test, the scripts do not need to do any clean up or similar.
+
+## Anatomy of a test case
+
+The `test.sh` script looks for an exectuable file called `run.sh` in each directory.
+When found, it is executed and signals success by returning a 0 exit code.
+Any other exit code is considered a failure and will halt execution of further tests.
+
+There is an `util.sh` file containing a few commonly used helpers which can be used by putting the following prelude to a new test case:
+
+```sh
+cd "$(dirname "$0")"
+. ../util.sh
+current_test=$(basename $(pwd))
+```