debian: fix dependency generation for python (Closes: #976597)

debian: fix dependency generation for python (Closes: #976597)

During the Debian 11 release cycle, we did a Xen upload at the same time
when a transition of default Python version (from 3.8 to 3.9) was
happening. This exposed a problem: Our xen-utils-V package just depended on
'python3'.

Why was this a problem? We ship a compiled extension, which gets built for
the *default* Python version in the system. In this case it was the
xenfsimage.cpython-39-x86_64-linux-gnu.so file (note the 39 in the name).

Having just the quite generic 'python3' dependency allowed our packages to
enter Debian testing before the transition of default Python version (from
3.8 to 3.9) did. As a result, the xenfsimage library could not be found,
because the user system would still be looking for [...]cpython-38[...].

To generate correct dependencies, dh-python >= 5.20211016 (which
includes a fix for #980303) is needed.

In the above case, the correct dependencies that would need to be added
are: 'python3 (<< 3.10), python3 (>= 3.9~)'. Having these dependencies in
place would make sure our packages enter testing at the same time as the
default change to Python would.

The actual patch in here is quite small, but not easy to understand as
multiple other bugs are also intertwined, so here follows more explanation.

First, this patch reverts 1ca529cc3c ("debian/control: fix xen-utils-4.14
python3 dependency"), which was a workaround for a missing python3
dependency in the xen-utils-V package. This problem happened due to
the dynamic ${python3:Depends} back in) is a prerequisite for the second part
below.

Second this patch adds scanning of the private directory
"/usr/lib/xen-$(upstream_version)/lib/python" for dh-python to detect
our private python extension and generate proper version dependencies
for python3. This unfortunately was broken in dh-python (#980303), but
is fixed since 5.20211016.
This part is the fix for #976597.

We were thinking about adding a build dependency to dh-python >=
5.20211016 to the xen source package, but decided to omit the version
from the dependency for the following reasons:

* A dh-python with all relevant fixes is meanwhile in unstable and
  testing.
* We wanted to make backporting xen to bullseye easy and dh-python >=
  5.20211016 is not in bullseye. Adding the versioned dependency would
  mean more manual work while doing the backport.

We believe this is safe to do for the following reasons:

* When building for unstable or testing in an up-to-date chroot there
  should be no issues as all relevant bugs in dh-python are fixed.
* When building a backport for bullseye, proper version dependencies for
  python3 will not be generated, but also have not been generated in the
  past, so this is not a regression. And, the default python3 version in
  bullseye will very likely never change.
* The revert of 1ca529cc3c might be seen as a problem as the dependency
  on python3 in xen-utils might be missing when compiled for bullseye.
  However this luckily does not happen because of our additional scan
  for private python extension in this commit. While the bullseye
  dh-python is buggy in a way that it doesn't generate proper version
  dependencies for python3 it still detects python3 usage and adds a
  'python3' dependency.

Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>
[ adding first three introductory paragraphs in the commit message ]
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>