MergeOp: Retry after computing ChangeSet

The problem with retrying the entire Submit operation when submitting a
topic is that submit may have succeeded for the first project attempted,
so the second attempt might fail unhelpfully with "Change N is merged".

Somewhat fortunately, there was a bug in the retry logic that was
preventing retrying from ever kicking in, because the UpdateException
was wrapped in an IntegrationException before escaping from MergeOp. Fix
this so that we can actually observe retry behavior in tests.

Improve the situation by using a subtler approach of retrying submission
of the entire ChangeSet, but using the same ChangeSet that was computed
on the original attempt. This means that for some projects, the
ChangeSet may, on retries, contain only merged changes. This requires
minor tweaks to MergeOp and deeper in SubmitStrategyOp to correctly do
nothing in that case. Behavior is still somewhat suboptimal because
postUpdate steps are not run for the projects that succeeded on the
first attempt, but this is not a regression.

Additionally, there was already a race when multiple submissions were
running at once, since MergeOp only checked the change state outside of
the BatchUpdate, not within SubmitStrategyOp. For this reason, silently
succeeding on already-merged changes is acceptable behavior.

Generating a lock failure during tests is somewhat messy, because due to
the implementation of FusedNoteDbBatchUpdate we need to actually insert
a failing command into the BatchRefUpdate.

Change-Id: Iae36e40369c40a125f6127125dc21e609c2b9b8d