The updateChangeStatus method was a little weird, basically following
disjoint codepaths depending on the value of the boolean dryRun
argument. The first time through, which happened immediately after
running the submit strategies, might throw exceptions for missing
dependencies or other invalid statuses. The second time through, after
executing ref updates, was actually responsible for setting the status
on the change objects in the database. (It could theoretically throw
in the same cases as the first time it was called, but those should
have already thrown already so it's essentially dead code.)
Split the first set of checks into a new method,
checkMergeStrategyResults, that has an explicit name for what it does,
and uses the same problem/failFast structure as we've started adopting
elsewhere.
Change-Id: I3ea6e5a47d3173749773c0cf7fa175c8048b1a0a
479e700631