Since we're now batching more change operations together into a single
transaction, the chance of a failure causing the change's state and
current patch set to not be updated is higher. Prior to using
transactions, this happened relatively early in the process.
Try harder to recover from this state: before attempting to merge a
change, see whether some patch set ref of that change has already been
merged, and if so, just fix up the state and patch set record.
This ends up being pretty complicated, and requires doing a bunch of
isMergedInto checks prior to merging. Hopefully in practice there are
not so many patch sets and/or they are close enough to head to not
make this too expensive.
Testing is a little tricky too. Teach Submit to accept a special
SubmitInput that tells SubmitStrategyListener to abort at a certain
phase, simulating some real-world failures.
Change-Id: I6922b5970c10fd9e074c1979d9eddb9103ac5d4f
dfbb9915cd