Acceptance tests for docker-compose Update Module

Exact method of testing this is somewhat up to the implementer to decide what is easiest, but which still provides good enough coverage. These are my suggestions:

• Treat the Gitlab "dind" container as the "device", since we can do Docker operations there.
  • For local testing, probably it is needed to execute the test inside a local dind container which can do Docker operations
  • One of the tests handles rootfs support, which will be missing, but all we need is the entry in mender.conf, so this can be faked.
• Use mender-test-containers for more comprehensive testing.

Acceptance criteria:

• Acceptance tests created for Update Module in MEN-3839, using a semi-real device.
• Must test at least:
  • Successful update from nothing = containers running afterwards.
  • Unsuccessful update from nothing = nothing running afterwards.
  • Successful update from previous containers = containers run afterwards, and none of the old ones do.
    • It's a good idea to have one container less in the new docker-compose file, to make sure that the old one being obsoleted is not being orphaned.
  • Unsuccessful update from previous containers = rollback works, and the old containers run afterwards, none of the new ones.
  • After successful update, check that old digest is not available in docker images --digest anymore.
• Everything passing in Gitlab