Fix race condition in bubble merge

[urbanautomaton]

We've recently started seeing occasional weird merges with squiddy, where the PR branch itself is merged and its commits land in master, but github considers the PR "closed" rather than merged, and having zero commits. (e.g. https://github.com/futurelearn/futurelearn/pull/14124)

The bubble merge action performs the following steps:

• we first rebase the PR branch using cirrus-actions/rebase
• we then merge the branch (NB: not the PR!) using the github API
• we delete the branch unless the repo is configured to do this automatically

None of these operations are directly on the PR, meaning that Github has to detect any relevant changes to the PR and update its state. This happens asynchronously, and is therefore prone to race conditions. I think the branch is getting merged before github notices the rebase, which it finds confusing (and who can blame it).

This PR tries to eliminate the possibility of race conditions by:

• Waiting for the PR head to match the branch head before merging (in other words, it gives Github a chance to catch up following the rebase)
• Issuing the merge command on the PR itself, not the branch

You can see this updated approach successfully waiting for the PR to pick up the rebase update here.

I've also done some removal of dead code and a bit of test tidying in the preceding commits.

Feedback

Seem legit?

[urbanautomaton]

Yeah, possibly. This particular use case is actually addressed by merge queues, a more recent github feature that's unfortunately only available in private repositories for enterprise subscriptions.

So if we ever stump up for the posh seats (or github deign to add this feature to regular teams) I'll be very glad to delete this code. 😄

[urbanautomaton]

@squiddy-bot merge

[urbanautomaton]

Okay, this appears to be working, here's the wait catching a branch mismatch over on a PR merge in the futurelearn repo.