test Release file handling with expired keys

Signing files with expired keys is not as easy as it sounds, so the
framework jumps a few loops to do it, but it might come in handy to have
an expired key around for later tests even if it is not that different
from having no key in regards to APT behaviour.

Git-Dch: Ignore
add chronic-like testsuccess/testfailure helpers

For many commands the output isn't stable (like then dpkg is called) but
the exitcode is, so this helper enhances the common && msgpass ||
msgfail by generating automatically a msgtest and showing the output of
the command in case of failure instead of discarding it unconditionally,
the later being chronic-like behaviour

Git-Dch: Ignore
fix: --print-uris removes authentication

The constructors of our (clear)sign-acquire-items move a pre-existent
file for error-recovery away, which gets restored or discarded later as
the acquire progresses, but --print-uris never really starts the
acquire process, so the files aren't restored (as they should).

To fix this both get a destructor which checks for signs of acquire
doing anything and if it hasn't the file is restored.

Note that these virtual destructors theoretically break the API, but
only with classes extending the sign-acquire-items and nobody does this,
as it would be insane for library users to fiddle with Acquire
internals – and these classes are internals.

Closes: 719263
fix output redirection order

First redirect output to a file, then redirect other outputs to this
output, not the other way around as this will not work.

Git-Dch: Ignore
do not try to chown if not run as root

If this code is run as non-root we are in a special situation (e.g. in
our testcases) where it is obvious that we can't enforce user/group on
any file, so skip this code altogether instead of bugging users with
an error message – which we also switch to a warning as a failure to
open the file is "just" a warning, so the 'wrong' owner shouldn't be
that much of an issue.

The file is still handled with chmod, so all the security we can enforce
is still enforced of course, which also gets a warning if it fails.

Git-Dch: Ignore
use our _error stack to generate openpty errors

While we don't want these error messages on our usual stack, we can use
our usual infrastructure to generate an error message with all the usual
bells like errno and strerror attached.

Git-Dch: Ignore
add a not documented apt-key --fakeroot option

Usually, most apt-key commands require root, so the script is checking
for being run as root, but in your tests we use a non-root location, so
we don't need to be root and therefore need an option to skip the check.

Git-Dch: Ignore
always use our own trustdb.gpg in apt-key

APT doesn't care for the trustdb.gpg, but gnupg requires one even for
the simplest commands, so we either use the one root has available in
/etc or if we don't have access to it (as only root can read that file)
we create a temporary directory to store a trustdb.gpg in it.

We can't create just a temporary file as gpg requires the given
trustdb.gpg file to be valid (if it exists), so we would have to remove
the file before calling gnupg which would allow mktemp (and co) to hand
exactly this filename out to another program (unlikely, but still).
use a tmpfile for trustdb.gpg in apt-key

for some "interesting" reason gpg decides that it needs to update its
trustdb.gpg file in a --list-keys command even if right before gpg is
asked to --check-trustdb. That wouldn't be as bad if it wouldn't modify
the keyring being listed at that moment as well, which generates not
only warnings which are not a problem for us, but as the keyring
modified can be in /usr it modified files which aren't allowed to be
modified.

The suggested solution in the bugreport is running --check-trustdb
unconditionally in an 'apt-key update' call, but this command will not
be used in the future and this could still potentially bite us in
net-update or adv calls. All of this just to keep a file around, which
we do not need…

The commit therefore switches to the use of a temporary created
trusted.gpg file for everyone and asks gpg to not try to update the
trustdb after its intial creation, which seems to avoid the problem
altogether.

It is using your also faked secring btw as calling the check-trustdb
without a keyring is a lot slower …

Closes: #687611
Thanks: Andreas Beckmann for the initial patch!
do not double-slash paths in apt-key

Closes: 665411
make the keyring locations in apt-key configurable

Might come in handy for more than just a simple testcase.
ensure that testcases exiting because of set -e aren't successful

Git-Dch: Ignore
let apt-key del work better with softlink and single key keyrings

Having fragement files means there is a good chance that there is one
key per keyring, so deal with that as well as with setups in which
keyrings are linked into trusted.gpg.d as we can't just modify those
files (they might be in /usr for example).
do not call 'apt-key update' in apt.postinst

The debian-archive-keyring package ships trusted.gpg.d fragment files
for a while now and dropped their call to 'apt-key update', so there is
no need for use to call it as the keys will always be available.

This also finally allows a user to remove key(ring)s without APT to
overriding this decision by readding them with this step.

The functionality is kept around in the odd case that an old
debian-archive-keyring package is used which still calls 'apt-key
update' and depends on the import (hence, we also do not enforce a newer
version of the debian-archive-keyring via our dependencies)
update changelog for upload