This reverts commit 75449088.

I need the test suite working to release 3.0~beta2, and it's been quite broken
on feature/stretch since the merge of test/12059-dogtail-optimizations.

refs: #12305

* "persistent": effects (e.g. assignments) survive between separate
  remote shell python commands.

* "Python 2.7": because that is what Dogtail needs.

* "per-user": the `dogtail` module must be imported as the user
  running the applications you intend to have Dogtail interact with.

This will allow us to optimize the performance of Dogtail
significantly, as well as reduce the code complexity of the Dogtail
wrapper.

Refs: #12059

We are experiencing lockups with the virtio channel that will need
further investigation.

Refs: #11887, #11888

The `||=` operator will do the assignment if the variable is `nil` *or*
`false`, which is a very unfortunate design decision. :/

... or face a failure.

So this is the actual workaround needed for #11874 it seems.

Will-fix: #11874

Sorry for the non-atomic commit.

Will-fix: #11874

Namely /tmp. The test suite's TMPDIR isn't necessarily writable for
libvirt-qemu, which is the user that tries to create the socket.

open_file() itself return's the RemoteShell:File object, not the last
value of the given block, which I must have imagined.

... instead of a TCP port.

We don't have #9223 yet, so the try_for() block must return `true` to
pass.

The serial channel operated at 400 Kbaud = 50 KB/s (although I think it
was significantly lower in practice) whereas we now should
expect (depending on hardware) rates closer to 50 MB/s, i.e. 1000x
faster.

... like reading a file, and writing or appending to a file. Now we can
read/write *any* characters without worrying that it will do crazy
things by being passed through the shell, as was the case before.

This commit also:
* adds some better reporting of errors happening on the server side by
  communicating back the exception thrown.
* removes the `user` parameter from the VM.file_* methods. They were not
  used, any way, and simply do not feel like they fit. I think the only
  reason we had it initially was because it was implemented via the
  command interface, where a user concept makes a lot of sense.

... to not "pollute" the global namespace with all our helpers. This is
an example of how we can work towards #9030.

Refs: #9030

While libvirt can handle it, it does so with a workaround. The correct
way to configure a (<driver name='qemu' type='raw'/>) cdrom device to
not contain any media is to not have the <source ..> tag at all.

The remove_cdrom code now unplug the whole device, which does not fit
when we just want to eject it. In place we use the `eject` command
inside the VM. It may be a bit less realistic than previously, but with
QEMU 2.6 we can't set the source file to an empty string.

Will-fix: #11874

This does not work, even in QEMU.

Will-fix: #11874

Otherwise we end up with duplicated CDROM devices.

Will-fix: #11874

Since QEMU 2.6, VMs can't boot if the CDROM has no ISO file provided in
the source field. We have to unplug and plug the whole CDROM device to
workaround this.

Will-fix: #11874

refs: #8183

Hopefully it will be less prone to lost key presses.

The old design was very inflexible, which over time lead to the
implementation growing messy as different checks were added. The
issue was that it had to hard-code the particular checks we
wanted, and did not allow the user to formulate an expression for
which packets are considered leaks or not. So, let's instead
provide an assertion-like function to which the user passes a
block describing how we want all our packets to look.

Furthermore, now all firewall leak tests should be ok with the
simulated Tor network provided by Chutney. Since all Tor nodes
(incl. bridges) run from the same host (and IP address) we also
include the server port when verifying that no unexpected hosts were
contacted.

Note that in some cases we've lost a bit of information and
precision, e.g. among the anti-tests we no longer exactly match
the protocol that was leaked, but that wasn't very valuable to
begin with, and instead we test *exactly* the code that these are
anti tests for -- a true anti test, indeed!

Also, the 'no traffic has flowed to the LAN' (now renamed) had a
serious bug which was fixed in passing -- the `@lan_host`
variable was not set, so it is `nil`, which could never be among
the IPv4 TCP leaks, so that step always succeeded! :S

This will greatly speed up VM.file_{append,overwrite}() and in
particular make it much faster to transfer Dogtail scripts.

We still see "Remote shell seems to be down" caused by a timeout,
and last time it happened the system was under heavy load.

I would like to discard any chance that we're simply not waiting long
enough. Given we wait up to 30 minutes for the system to boot, we can as
well wait for a few more dozens seconds for the remote shell to start.

They try to do the same thing, but the former uses uglier parsing
(imho) and fails if the test suite is run as a non-root user since
ifconfig is in /sbin, which generally isn't in such users' PATH:s.

It seems the clipboard is cleared between these steps of the wizard.

Sorry for the code duplication. Something will be done about it later:

Refs: #10864

I looked at how virsh does it (the --eject option), and it removes the
<source> element (specifically *without* the DEVICE_MODIFY_FORCE, so
we drop it), claiming it is "the documented way" but I failed to find
any reference to this. Any way, it works, although Libvirt thinks it
doesn't, throwing in error that we carefully has to match and ignore.

The 'tray' attribute cannot be updated on running domains, and for our
purposes (refs: #5472) it's not useful for stopped domains.

Will-fix: #5330

I.e. set the clipboard to exactly the intended clipboard text.