refactor executeReplay to make it more testable.

[levlaz]

Right now its pretty hard to write a unit test for this function because its calling commands outside of the process and not capturing any output.

We should use subprocess instead of run.

This will allow us to mock some responses and verify that the commands are being ran as expected.

[levlaz]

Looking back on this I don't think that run is necessarily the issue here. I think I had a poor understanding of what run is doing. We can get similar introspection of command output using run, we just need to make sure that we are capturing it.

From the run docs:

Run command with arguments and return a CompletedProcess instance.

The returned instance will have attributes args, returncode, stdout and stderr. By default, stdout and stderr are not captured, and those attributes will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture them.

If check is True and the exit code was non-zero, it raises a CalledProcessError. The CalledProcessError object will have the return code in the returncode attribute, and output & stderr attributes if those streams were captured.

If timeout is given, and the process takes too long, a TimeoutExpired exception will be raised.

There is an optional argument "input", allowing you to pass a string to the subprocess's stdin. If you use this argument you may not also use the Popen constructor's "stdin" argument, as it will be used internally.

The other arguments are the same as for the Popen constructor.

If universal_newlines=True is passed, the "input" argument must be a string and stdout/stderr in the returned object will be strings rather than bytes.