Avoid trying to migrate SCMTool IDs during pre/post-upgrade.

Review Request #12410 — Created June 24, 2022 and submitted — Latest diff uploaded

Review Board

When we perform a database upgrade, we try to build up a map of any
repositories that need to be updated. We try to be careful, selecting
only the specific repository fields we need and deferring the rest, in
particular, scmtool_id, because that field may not exist during the
upgrade process.

Unfortunately, my addition of a signal handler to lazily upgrade
repositories that couldn't be migrated at this stage (due to uninstalled
extensions and such) broke this. It would attempt to access
scmtool_id, which would cause a database query to fetch that value,
breaking when the evolution hadn't yet been applied.

This change avoids any scmtool_id migration attempts if working with a
repository containing any deferred fields.

In a way, this is a bandaid. A better solution may be to have state that
says "we're doing upgrade operations, please hold" and allow code to
check that. But that'll come later.

In the meantime, this is still a good fix to keep around, as it avoids
extra database queries that may not be wanted.

All unit tests pass.

Tested this in production when hitting this problem during the upgrade
process, which broke due to the field query. This fix allowed the upgrade
to take place.