Build defenses against setuptools

[rmol]

Description

We have been regularly derailed by setuptools breakage (#5212, #5150, #5471, etc.), despite several attempts to control its installation and usage in our packaging process. And it's just suboptimal to have no control over the versions of tools used to build our production packages (#5109). We should figure out once and for all how to pin it to a working version absolutely everywhere.

We made some progress with the alternative build system of dh-virtualenv in #5472, but it has serious bugs, and there are ongoing questions about how to include recent versions of dh-virtualenv in the Xenial container.

There are also some promising suggestions in #5109.

[conorsch]

Note that the setuptools team has reverted the changes that led tot he breakage in #5471: pypa/setuptools#2376 Even so, the resilience we added in #5472 is well worth maintaining, simply to keep the build process on the rails over time.

[kushaldas]

We once tried this already in #5110

[eloquence]

@rmol and others will continue to investigate this during the 9/3-9/17 sprint. Options that have been explicitly suggested:

• Use of the --no-download option of virtualenv to prefer the system version of setuptools: https://virtualenv.pypa.io/en/latest/cli_interface.html#no-download
• Use of Python's built-in venv (see previous attempt in Use system provided pip/setuptools #5110)

If these options don't work, we at least want to make sure we address the build behavior regression observed in #5472 (comment) e.g. via in-place substitution of the path name; though we've not identified any functional regression as a result of this path breakage, we don't want to ship from develop until this is resolved.