Apply "pyupgrade --py3-plus" to most remaining files
There are a couple of non-production scripts in `utilities/` and their
dependencies that still require Python 2, as well as the code in
`lib/contrib/` that's copied from elsewhere pending replacement by
dependencies from PyPI and that's better to leave alone. Everything
else that `pyupgrade` knows how to deal with now uses Python 3 syntax.
Tolerate git commits with invalid author/committer emails
`email.utils.formataddr` requires email addresses to be ASCII, per the
email RFCs, and raises `UnicodeEncodeError` if they aren't. However, by
the time a commit gets this far, we need to do something with it (it may
be an import from a repository hosted somewhere else, in which case we
wouldn't even theoretically be able to reject the bad metadata on push).
Leave the author or committer unset in this case and ensure that we can
still render the commit properly when we need to.
Rename conjoined master/slave bug tasks to primary/replica
Launchpad bugs have a peculiar feature called "conjoined tasks". For
example, the tasks on a bug that's being primarily worked on in the
jammy series of Ubuntu but whose fix then needs to be backported to
focal and impish might look like this:
base-files (Ubuntu) Status tracked in Jammy
-> Focal Triaged Critical
-> Impish Triaged Critical
-> Jammy In Progress Critical
In this case, the task on base-files (Ubuntu) is currently referred to
as a "conjoined slave", and the task on base-files (Ubuntu Jammy) is its
corresponding "conjoined master". The metadata of the conjoined slave
cannot be updated independently; instead, changes are automatically
propagated from the conjoined master.
This terminology obviously doesn't fit with inclusive naming standards.
Rename "conjoined master" to "conjoined primary" and "conjoined slave"
to "conjoined replica", which I think also expresses the metadata
replication relationship a little more clearly.
I also considered renaming "conjoined master" to "conjoined
series-specific task" (or `conjoined_specific`) and "conjoined slave" to
"conjoined generic task" (or `conjoined_generic`). That had the
advantage of making it clearer which way round the tasks go (which I
always find confusing and have to look up), but it's more cumbersome in
prose, and it makes the replication relationship less clear.
