Rare race condition between merging a PR and "Scan for updates" workflow

[fingolfin]

Last night I merged PR #673. But when I merged it, the "Scan for updates" workflow was already running, and promptly produced PR #673.

I think what happened is roughly this:

1. the workflow got started per its schedule, at the then current commit a320275
2. while it was running, I merged PR [profiling] Update to 2.5.2 #673.
3. the workflow proceeds and determines that profiling was updated compared to a320275
4. so a new PR was opened (because no open PR for profiling existed at this point, as I had already merged it.

I am not sure how to prevent this or if it is even possible. But we certainly can lower the probability of this happening: e.g. just before opening the PR the workflow could perform a git pull and abort if there are no changes afterwards.