u-u: import "email.genators" package early as workaround

[mvo5]

This commit works around an issue when python itself is upgraded
by u-u and the content of email.message now needs a newer email.errors
but u-u already (implicitely) loaded that module so there is a
old version in sys.modules. So instead import email.generators early
so that it is available in memory and there is no mismatch.

See python/cpython#124170 and
https://bugs.launchpad.net/ubuntu/+source/python3.8/+bug/2080940
for details.

Unfortunately while this commit fixes the autopkgtest failure that
is now triggered by this the real issue that the users see is not
fixed because the "old" unattended-upgrades will perform the upgrade
and it will upgrade both the problematic python and the fixed u-u
but because u-u does not re-exec the "old" u-u still runs and the
fixed code from u-u will not be used.

Thanks to Julian Klode for his excellent analysis.

[julian-klode]

It does but it's also not doing anything at all for this issue - the python update is already released and we can't make unattended-upgrades upgrade itself first and then re-exec itself to enable the fix.

For the future proofing, it may be nicer to avoid the lazy import inside the function and handle all imports up-front, but I don't think that helps enough because the email module imports more modules dynamically.

It's been some time since looking at this.

[mvo5]

It does but it's also not doing anything at all for this issue - the python update is already released and we can't make unattended-upgrades upgrade itself first and then re-exec itself to enable the fix.
[..]

Yeah, that is of course true, merging this at least helps with the autopkgtest failure. I guess if we wanted to fix for real we would have to add a "Breaks: u-u (<< 2.12)" to the problematic python upgrade, then send a sigterm from the u-u postinst to u-u itself for this one upgrade. This should stop it gracefully and then the postinst would have to restart it by triggering the daily time job again. But that of course is all pretty ugly and error prone :( Plus the problematic update went out a while ago already.

For the future proofing, it may be nicer to avoid the lazy import inside the function and handle all imports up-front, but I don't think that helps enough because the email module imports more modules dynamically.

Another idea for future proofing might be to always upgrade u-u first and re-exec if u-u is part of the upgrade set(?).

It's been some time since looking at this.

Thanks, for your super useful analysis :)

I will merge mostly for the benefit of autopkgtest but you are right, this will not help with the real issue unless people upgrade u-u manually early.