This further abstracts some of the setup and teardown code so it can be
used for git-over-http tests.
It also moves the code that was originally added to the archive
state integration tests to create a local http server into
salt.support.helpers so that it can be more easily and portably used.
This does the following:
- Splits states for container/volume/image/network management into four
separate state modules.
- Preserves backward compatibility by making ``docker.image_present``
invoke ``docker_image.present``, etc.
- Changes how Salt detects that a container needs to be replaced.
Instead of comparing each passed argument to the named container's
configuration, it creates a temporary container, and compares that
container to the named container. If the two differ, then the older
container is removed, and the new one is renamed and started, becoming
the named container.
- Removes the unit tests for container management and replaces them with
integration tests.
- Adds unit tests for the new salt.utils.docker
The tornado web aplication that was set up in the archive tests, and then
duplicated in the remote file integration tests, starts the web server,
but never stops it. This creates a stacktrace that hangs the other test
file that attempts to start the web server.
The Application class has a `listen()` function, but not a `stop()` function.
The change uses the `HTTPServer` class to set up the listening server, but
also has the necessary `stop()` function. (The `listen()` function from the
`Application` class just calls out to the `HTTPServer`'s `listen()` function,
so this works nicely here.)
We can then call the `stop()` function in the `tearDownClass` class method.
I also removed some duplicate STATE_DIR definitions.
Put the skipIf and the destructiveTest decorators on the class instead
of each function. Also added a user.absent to the tearDown to reduce
code duplication.
Python 3 didn't like some of the stuff that we were doing with
``subprocess.check_call()`` in these tests, so to fix this I have redone
that stuff with calls to functions in the git execution module. In order
to avoid problems with running tests with no global gitconfig, I needed
to add an argument called ``git_opts`` to most of the funcs in the git
execution module (well I didn't *need* to do it to most of the funcs, it
just seemed like we shouldn't only be supporting this argument in a
single function).
This new ``git_opts`` argument is specifically for passing arguments to
the git command itself (not the subcommand). For example, ``git -c
user.name="Foo Bar" commit .....`` is different than running ``git
commit -c user.name="Foo Bar" .....``, because the ``commit`` subcommand
for git also accepts ``-c``.
