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

... to significantly improve Dogtail's performance by saving state and
reusing it between Dogtail commands.

This is a massive commit, and it changes the semantics of the creation
of Dogtail objects. Previously they just created the code that then
would be run once an actionable method was called (.wait, .click etc),
but now it works like in Python, that Dogtail will try to find the
graphical element upon object creation.

Will-fix: #12059

* "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

Calling socket.readline() and then just wait for the data to arrive is
prone to stalling for some reason. A timed read() can perhaps work
around this.

It's gotten too convoluted and seems to cause remote shell timeouts
itself.

This is ugly stuff that we definitely will revert or nuke from the Git
history.

It's what we actually want here, since we do not want to retry on
failure. Also, let's include the sending of the request inside the
timeout as well, not only the response waiting.

For now, let's just focus on remote shell timeouts, and for that let's
be really sure we only catch *remote shell* timeouts, and not try_for()
timeouts thrown from "outside" when wrapping around remote shell usage.

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

... after 20 minutes, by default, and it is no coincidence that it is
distinctly lower than our Jenkins' setup's timeout. For commands that
may require longer timeout (or none) there's an option.

I've seen frequent lockups that could be explained with buffering, so
let's see...

... instead of a TCP port.

Since most string methods are line-centered this makes the code more
readable, and it is also less surprising. I believe the only reason for
picking \0 was in case the command contained a newline, but at least
that has not been the case since we started packing them using JSON.

The "_helper" part is redundant, and it's not only about execution any
more, but also the file operations provided by the remote shell.

... 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

I've never seen the retrying (which would manifest it self with two+
@debug_log()@ calls) happen for any _real_ use of the remote shell, only
for the first one during `VMCommand.wait_until_remote_shell_is_up()`,
and it does its own retrying.

When a remote shell call is aborted while the command is executing, the
next remote shell call will get as response the response meant for the
aborted call. Using this unique ID we can make sure that requests will
only get the intended responses.

Will-fix: #11846

onioncircuits now uses tor-controlport-filter, which is exposed to the
live user. Also the per-process filtering should make the attack surface
even smaller.

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

refs: #6841

refs: #6841

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.

It's always the same (=> useless) any way.

There's some code simplification too, and the removal of the
@new_circuit_tries counter, which is all over the place and is a bit
hard to keep track of.

Also for the wget/whois test we do not try to detect if Tor was the
problem and only force a new circuit (and hence count it as a retry),
since that could lead to an infinite loop. With the new helper, we
always do MAX_NEW_TOR_CIRCUIT_RETRIES number of retries.

It seems something in this branch (test/7821-tor) has made this
function fail somethimes, possibly commit 1a55905 (Create the
environment for remote shell calls more realisitcally).

Trying the initial test command several times like in this commit
seems to fix it, and the the client and server in sync. Let's see how
it goes.

In many tests we execute VMCommand:s without checking the return
status, assuming success and that the stdout we get is fine. In some
cases this assumption could potentially result in a test passing when
it should not.

systemtimer was relevant in Ruby < 1.9 (and is only available in for
such versions of Ruby in Debian).