Due to changes in upstream gerrit, our merge commits now throw an error when loading/querying.

Root cause: When the Qt Workflow Plugin was originally developed, Gerrit could not perform cherry-picks of merge commits. As a workaround, the plugin instead merged the merge commit directly to the target branch and created a new patchset with the same commit SHA as the latest user-uploaded patchset.

When https://gerrit-review.googlesource.com/c/gerrit/+/376877 added new functionality for fetching the parent of a change, it performs a check on a given parent of a change that exactly one patchset of that parent change matches the expected sha of the queried parent (ParentDataProvider.java:116). Due to our previous workaround, there are two patchsets in merge commits with identical shas, causing this new check to fail and throw an exception.

Workaround: Since we know both patchsets containing the expected parent match the same parent sha, and the latter is a virtual patchset, we can safely select the first patchset when querying parents.

Long-term fix: The git history of merge commits must be corrected to refer to only the real final patchset which made it to the target branch. This is done by editing the last two commits of refs/changes/xx/[change-number]/meta to edit the patchset number and remove references to Commit, Groups, and Subject.

Further, the workflow plugin must be updated to either: perform a cherry-pick in order to merge all change types including merges, or avoid adding Commit, Groups, and Subject footers to meta commits, referring only to the current real patchset.