Refs: #9430

Fix-committed: #9329

The root user has special memory overcommit rules that may allow it to
allocate memory enough to make the system unusable. Let's run fillram
as a non-root user instead, to prevent the VM from stalling.

Previously we set oom_kill_allocating_task so the allocating process
would be OOM killed. If we're really unlucky, that could be some other
vital process, like the remote shell. Now we do not set
oom_kill_allocating_task and instead set a high oom_adj for each
fillram process instead.

The remote shell script name has changed, but we used the old name, so
we actually never set the oom_adj for it. Behold the power of
execute_successfully(), which discovered this issue!

The kernel documentation says [1] that "if you set this to lower than
1024KB, your system will become subtly broken, and prone to deadlock
under high loads." This may explain why the VM sometimes becomes
unrepsonsive, so let's not do that.

[1] https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Fix-committed: #7249

Fix-committed: #9066

Merge remote-tracking branch 'origin/bugfix/9126-deny-tor-browser-access-to-recently-used' into stable

Fix-committed: #9126

Fix-committed: #9364

Fix-committed: #9523

And then: drop our own copy of that script, and adjust setup documentation
accordingly.

Will-fix: #9066

Will-fix: #9126

Fix-committed: #9406

Otherwise, a Wheezy builder fails to build a Jessie ISO, and vice-versa, because
Wheezy's and Jessie's eatmydata put their LD_PRELOAD'ed libraries in
different places.

Will-fix: #9523

Fix-committed: #9344

Fix-committed: #9355

Fix-committed: #9286

Merge remote-tracking branch 'origin/test/9425-enable-spice-and-asbolute-pointing-device' into stable

Fix-committed: #9425

The tests will sometimes fail becase of errors communicating with the
keyservers and because of Seahorse segfaulting. The purpose of this
helper function is to make the cause of such failures easily evident.

(Related to #8298)

Will-fix: #9344

This will fix a similar problem to #8928, which seems to correlate with
CPU load on the host system running the test suite.

Fix-committed: #9402

Fix-committed: #9339

Fix-committed: #9416

Not only this introduces needless variations between ISO images built from the
same source (hence blocks deterministic builds), but there's a risk that some
package (either one we already ship, or one that we ship some day, or one that
users install themselves) actually use this pair of SSL keys on the Internet,
which is wrong since the private key material is public.

Note that:

 * We run update-ca-certificates after deleting the snakeoil SSL certificate,
   to ensure it's not included in /etc/ssl/certs/ca-certificates.crt.
 * We make sure we delete all symlinks pointing to the SSL snakeoil certificate
   or key, because it avoids having to understand what symlinks are created
   on current Debian, and to track any future changes in this area.

Will-fix: #9416

Fix-committed: #9341

Will-fix: #9339

Now that Linux 3.16.7-ckt9-3 has migrated to Debian Jessie (well,
jessie/updates), let's install the kernel from there instead of Debian
testing, so we won't get Linux 4.0 at some point, which will break
aufs.

This is a follow-up to #9340.