commit b81f56c4699d2562c69508b110bd4faa81cdb200
author Gal Paikin <paiking@google.com> Wed Oct 16 14:39:24 2019 +0200
committer Gal Paikin <paiking@google.com> Fri Oct 18 11:13:26 2019 +0200
tree 031bb47b1c228ab0b688aa5b31784f2957f8ce38
parent 7ec002bc471822a81b0f4506b7ddf173613acdfc

Allow revert by submission

When a change in Gerrit is submitted, it's possible that the submission
includes other changes:
1. Open parent changes (unless the submit type is cherry-pick).
2. Open changes with the same topic (if change.submitWholeTopic in
gerrit.config is set to true). Those changes with the same topic could
be in different repositories or different branches.

If the submission of a change introduced an issue, users often revert
the change to resolve the issue, but this may cause breakages if the
change had been submitted together with other changes. Usually changes
that are submitted together depend on each other, so that reverting
only one of the changes breaks the other changes. Hence if a submission
contains multiple changes, one needs to revert all of the changes which
have been submitted together. At the moment this can only be done by
calling the Revert Change REST endpoint for each of the changes one by
one.

The new Revert by Submission REST endpoint allows to revert all changes
of a submission. Since we don't have REST resources that represent
submissions, the REST endpoint is offered on change level, meaning that
this change and all changes that have been submitted together with this
change should be reverted. It's a new REST endpoint, rather than a new
flag for the existing Revert Change REST endpoint, because it needs to
return a set of revert changes which can't be done from the Revert
Change REST endpoint without breaking backwards compatibility (the
result of the existing Revert Change REST endpoint is a single change).

The only functionality added here is the ability to revert all
changes with a single button. However, the changes will not be rebased on
top of each other so the users may need to rebase them manually to make
them submittable.

The Revert by Submission REST endpoint has the following steps:
1. Check that the change for which the Revert by Submission endpoint is
invoked is merged. A change that is not merged does not have a submission
ID and thus we can't revert the submission of such change.
2. Find all changes that were submitted together: For this we take the
submission ID of the change on which the REST endpoint was invoked and
query for all changes with this submission ID. The ID of a submission is
already contained in the change index and internally we can easily query
changes by it (although querying changes by submission ID is not exposed
to users).
3. Next we make all necessary validations such as permission
validations, and ensuring the existence of all the changes.
4. Revert all changes one by one using the Revert REST endpoint. Each
newly created change will have a topic that was given by the user, or a
default "revert-<submission_id>-<random_string_of_size_10>".

What happens when users revert the same submission twice?
- Duplicate revert changes are created but they will have different
unique topics.

What if a submission contains a single change?
- The result is similar to the result of the Revert Change REST endpoint.
The only difference is that the topic of the revert change is set to
'revert-<submission-id>-<random_string_of_size_10>'.

Next steps:
* Optionally, when the revert submission is finished, the user should
see a list of the revert changes.
* When reverting a submission through the UI, the user should insert
the reason for reverting this submission.
* [Optional] Revert Submission action should show a preview of the
changes that are going to be reverted.
* Make the reverts stack on top of each other when in the same branch
and in the same repository. It should always succeed since it will not
rebase on top of the destination branch.
* Add an option to rebase automatically on top of the destination
branch.
* [Optional] Add an option for interactive revert that allows the user
to resolve conflicts when occur (similar to interactive rebase).
* Create all reverts in a single batch. This way we also avoid multiple
permissions checks.
* [Google only] Consider using sharded computation, similar to submitting
together multiple changes across multiple repositories.

Change-Id: I7188c0d520afa669fd78309c39d44656c38259dd