Add workarounds to check run getting stuck

Currently, whenever we get a CI event notification from GitHub, we ignore it and refetch from the GitHub API the status of the CI jobs. This way, if GitHub or the merge bot flakes and fails to send/handle the status of a CI job, a later CI notification will include that result.

But we’ve seen that sometimes, CI will finish, but the Merge Run check page still shows a job in progress. This might be a race condition, where GitHub sends the notification “CI Job A finished” but its API hasn’t finished updating, so when we query “get status of CI jobs”, CI Job A might still be marked as in-progress. Note that the merge bot getting stuck is rather rare; first, this race condition has to occur, but it has to occur on the very last job, since another CI notification would handle the updated status for this job.

I think the best solution would be to add another poll in the merge bot that regularly (e.g. every 10 minutes) pokes a merge run to refetch CI job statuses from the github api. In the common case, this will never do anything, since each CI event should trigger this, but in the edge case described here, this would give us a fallback. Alternatively, we could just add an action to the Checks page that "pokes" Mergit to refresh the check run.

This would resolve #138, which was mostly trying to solve this problem. After this is solved, the "Reset merge run" button should only be used on the rare instance where a PR is merged but Mergit still thinks it's running.

Start by tracing how CI event notifications trigger GitHub API status refetches in the merge bot; the issue does not name files or tests. Compare the proposed periodic poll with a Checks-page refresh action, and consider the work done when a final-job race no longer leaves a merge run stuck and Reset merge run is only needed for the stated rare case.

Written by the indexing model from the issue text.