Clarify confusing comments around restricted processors
Comments in several tests used the terms "enabled" and "disabled" to
talk almost interchangeably about both (1) whether an archive or recipe
is allowed to dispatch builds for a given processor and (2) whether the
corresponding UI checkbox is greyed out or not. This could very easily
cause confusion, so rewrite these comments to be more explicit about
what they mean.
Profiling shows that most of the time is spent in
`storm.references.Reference.__get__` filling in foreign key references
from the Storm cache. Drilling down further, most of the time is spent
in the implicit flush at the start of `storm.store.Store.get`: there are
many JSON variables in the cache, and since those have mutable values,
the flush process has to dump each one of them to find out whether
they've changed. This got substantially worse with the use of
`PackageLocation`s in the dominator, since constructing those involves
following several foreign key references for each publication.
A reasonably well-contained fix for this regression is to block implicit
flushes in the dominator. This does mean that we have to be careful to
add explicit flushes after each piece of code that should result in a
change to the database; any intervening code that might load objects
into the Storm cache could discard unflushed changes.
In the longer term, it might be possible (if fiddly) to augment the
mutable values owned by JSON variables and similar with `__setitem__`
methods that recursively keep track of changes to the object; for
example, SQLAlchemy allows that kind of approach via
`sqlalchemy.ext.mutable`.
