Explicitly order CodeReviewCommits when merging

The commits passed in to SubmitStrategy#run were coming straight
out of ChangeAccess#submitted, which should generally use primary
key (numeric change ID) order; these CodeReviewCommits also had
their originalOrder fields set based on this order. SubmitStrategy
implementations were implicitly relying on the order of the List
argument, which results in commits sharing no ancestry being merged in
change ID order. However, merge-based strategies were also re-sorting
the list via MergeUtil#reduceToMinimalMerge, which used the
originalOrder to re-sort the results after reducing the merge.

Instead of these multiple subtle layers of implicit and explicit
ordering, change the SubmitStrategy interface to take Collections, and
make implementations responsible for ordering the commits that are
passed in. This results in a small amount of repeated code, to sort
the inputs, but this is made manageable by adding an explicit Ordering
to CodeReviewCommit. The advantage is that we no longer have some
implementations sorting and some not, so the semantics of the
SubmitStrategy class are slightly more straightforward.

Change-Id: Ia6b0166cdd8b8b331989bf948de3b28b0480d249

gerrit-server/src/main/java/com/google/gerrit/server/git/MergeOp.java

@@ -496,7 +496,6 @@ public class MergeOp {
       tips.add(r.getObjectId());
     }
 
-    int commitOrder = 0;
     for (Change chg : submitted) {
       ChangeControl ctl;
       try {
@@ -568,7 +567,6 @@ public class MergeOp {
 
       commit.setControl(ctl);
       commit.setPatchsetId(ps.getId());
-      commit.originalOrder = commitOrder++;
       commits.put(changeId, commit);
 
       MergeValidators mergeValidators = mergeValidatorsFactory.create();