Now that mergeability is checked lazily using a cache upon reindexing,
we can ditch the specific mergeability-rechecking codepath and just
depend on the cache to load properly. This reduces complexity of
background merge checking in a number of pleasant ways:
- We don't have to maintain two sets of background threadpools.
- Since the cache loader looks at project configuration and runs
submit rules, we don't need to guess in the ref update listener
whether submit rules might have changed in a way that affects
mergeability. If the cache key is the same, it's a hit; if not, it
isn't.
- No more --recheck-mergeable flag to reindex; checks only happen for
those changes that are actually outdated. (We might need to trigger
a full mergeability recheck at some point in the future, but we can
do that by simply flushing the persistent cache.)
- The check interface is pared down; we never actually used arbitrary
lists of projects/branches/changes.
- The ref updated listener can always use background priority, while
callers indexing a single change naturally always use interactive
priority.
- No manual locking to avoid duplicate work; LoadingCache takes care
of that for us.
- Mergeable is not used by the reindexing path, so we don't need to
explicitly turn off reindexing in that handler.
The configuration values for mergeability check threadpool sizes are
now used as fallbacks when the index threadpool sizes are not
configured.
Change-Id: I88ae7f4ad417fcba5495b2a5e4b94adf11e2a21b
0916cc3605