All these point to valid https: resources, but there is a small chance
that some unusual interaction will cause it not to work. Some of these
changes also won't take effect until the server is restarted, so we'll
need to keep this in mind if failures occur long from now.

These are for use by humans only.

The test jobs seem to be working as desired, so make them actually
start deleting the old files every 4 hours. Use -ignore_readdir_race in
all of them to avoid errors when schedbot cleans the files in the middle
of a run (an unlikely situation because of the clean-up times involved).

Even if 9/nonfree/backports_testing/ hasn't had any builds recently, it
shouldn't be deleted. Only delete directories deeper in the hierarchy.

Follow-up to f7e017e8

It's now confirmed that tidy() has been creating huge (2.6 GiB) state
files that the Puppet agent loads before every agent run, which causes
runs to take up to 4 days each and use of all RAM on the server.
Cleaning files using find is more straightforward and efficient and
avoids this problem.

The tidy() functions are disabled here and the cron jobs aren't actually
deleting files yet, so a follow-up commit will enable deleting
imminently, once testing shows it will work.

Follow-up to 59d57245

The Puppet method for doing this seems to be what's causing its memory
usage to reach the size of the physical RAM in the system and take up to
4 days to complete a Puppet run. The test will show the files being
deleted and how long it takes, but won't actually delete them.

Sometimes someone moves a package manually and we end up with several
versions of a package.
In this case we should delete the src.rpm and handle its binary
packages like if it was gone.