Make Jenkins slave service startup more reliable and fix its status information (Closes: #8508, #11858).

This fixes two related problems:

1. The initscript tried to download the JAR only once. If the Jenkins master was
not reachable at that time, the service would be considered to be correctly
running, while it would not work at all. Let's now retry to download a JAR a few
times, with a power-of-2 backoff delay, in order to wait for the Jenkins master
to show up. And whenever the download script gives up eventually, systemd
(with Restart=always) will itself restart the service a number of times.

2. The service status (reported by the unit file auto-generated from the
initscript) was always "running", because that unit file had Type=forking and
the initscript runs plenty of commands before actually starting the service,
which makes systemd guess incorrectly what process it should monitor. This made
it impossible for our monitoring system to alert us whenever this service was
not functioning. Converting to a native systemd service with Type=simple makes
systemd report correct service status information.

Wheezy was archived on the Debian infrastructure so let's install it from our
custom APT repo until we get around to upgrading to v3.

tails::gitolite currently sets up Wheezy APT sources, but Wheezy was archived
on the Debian infrastructure, so these sources don't work anymore.
Let's import the version of Gitolite we currently run in our custom
APT repo until we get around to upgrading to v3.

We now have a guarantee that $ensure is either 'present' or 'absent'.
So no need to copy that value into a new $package_ensure variable.

Based on bertagaz' commit fb72d656,
but:

 - started from scratch since the underlying code base has changed
   too much in 22 months for that commit to apply cleanly

 - updated REAME

Custom APT repo: delete .buildinfo and .udeb files found in the incoming directory at boot (Closes: #16576)

check_mirrors: create per-run temporary download directories in a place that's cleaned up at boot time.

… and set the limit to 100, which is currently the maximum API
limit in redmine (see https://www.redmine.org/issues/16069).

Credits go to Enrico Zini.

redmine-remind: return more complete results by raising the number of issues we fetch (refs: #16544).

As Enrico said, "I wouldn't trust redmine not to have spaces in usernames, see:
https://www.redmine.org/issues/811".

Written by Enrico Zini, imported from
https://redmine.tails.boum.org/code/issues/16544#note-8

Let's spam the admins of this service a bit less when there's a problem.
A 8h max delay to notify them is acceptable.

We're migrating away from that legacy module and I've found no equivalent
anywhere else. Looks like other folks are fine with package upgrades
performed without Puppet break their custom permissions until the next
run of the Puppet agent.

This defined resource has no dependency, is very small and mostly trivial,
so let's not bother creating a dedicated new module for it.

The puppetlabs/apt module does not support this functionality
but for Stretch and newer systems, all the apt::reboot_required_notify
class does is installing that package anyway, so let's do that ourselves
and avoid inserting useless layers of abstraction.

Replace apticron with functionality included in APT + our existing monitoring checks (refs: #15510).

The puppetlabs/apt module, that we're going to switch to, does not support
apticron. We use apticron on exactly one system (lizard) that we don't want to
automatically upgrade. What we need is:

 - Downloading updated packages lists regularly: that's what APT::Periodic does.
 - Being told that we need to upgrade packages: we have a monitoring check
   for that. We don't need an extra email.

Let's start to migrate away from relying on the legacy
shared-puppet-modules-group/apt module for functionality it provides, that's not
supported by puppetlabs/apt.

LimeSurvey: make "git clone" command work even when run by a Puppet agent manually started from a non-world-readable directory.

Otherwise, the local master branch won't be updated when
tails-monitor-limesurvey-releases fetches from the upstream repo, and then no
new security release will ever be detected nor notified to the administrator of
our survey service.

MooX::Options stopped automatically converting e.g. --git-dir to --git_dir.

The fix for #6907 made it upstream and eventually to Buster,
so we can stop running a custom, patched package.