Signed-off-by: NMark Hymers <mhy@debian.org>

This is recommended by PEP 8.

Also remove some warnings that are no longer raised.

Reference: https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator

Both callers were using `split()` to get a list already.  So we should
just return a list isntead of `join`ing and `split`ting.

Also make the way the gpg command is constructed in the callers look a
bit nicer.

It could look a bit nicer, but at least it works for now.

Broken in 4549ed9a

The additional packages below `overlays` were overlooked when
49a2b800 switched the test packages to
a non-deprecated debhelper compat level.

We already did not request external signatures for uploads going to
NEW, but we also do not want them for uploads as policy queues such as
"stable-new".

For the "embargoed" policy queue, uploads get copied to the build
queue which should still result in an external signature request.

Before we used the codename also as the suitename.

Reference: https://bugs.debian.org/714726

It's slower than the Python 3 tests.

Note that `hash` might not return the same value for one of these
objects and a `str` that the custom `__eq__` compares equal.  We
should probably get rid of the `__eq__` eventually.

On Debian 11 (bullseye) with Python 3 the test otherwise failed
with SQLAlchemy complaining:
```
    TypeError: Incompatible collection type: dict_values is not list-like
```

The condition was always true as `binaries` and `sources` are query
objects and not lists.  We only want to update `last_changed` when
either query actually returned something.

This addresses warnings that debhelper compat level 9 is deprecated in
newer debhelper versions.

The interface changed in incompatible ways between Debian 10 (buster)
and Debian bullseye.

There are incompatible changes in some Python modules that make the
tests fail. As it is a new test, allow the failure until this is
fixed.

Some Python 2 modules no longer exist in Debian bullseye, so trying to
satisfy all build-dependencies in d/control would fail there.  For now
just install them in `run-ci` where we can modify the list of package
to install dynamically.

This way we can also run Python 3 tests in parallel without requiring
more resources in total.