Refresh PR bodies "Just In Time", to avoid racey edits

[keithamus]

The duration of the build can result in a long window of time between the point in time when the PR comment body was initially fetched, to the time it was updated at. This can cause issues if users try to update the issue body while the build is processing.

Steps to reproduce:

1. Make a PR in e.g. whatwg/html
2. Edit the comment.
3. Edit it again within ~1minute
4. Notice that your second edit has been removed and replaced with the contents of the first comment, plus the rendered body.

This change implements functionality to refresh the body right at the point where the change list is rendered. This wont eliminate the problem but should sufficiently minimise the window of time between the build start and the time at which the comment data was fetched to hopefully render this issue hard to reproduce.

[tobie]

Thanks for the PR. I'm assuming this covers the case where just the body of the PR has changed but not the PR itself. Have you considered possible race conditions if the PR itself was modified during that timelapse and whether that's something you wanted to check for (and maybe do something about)?

[keithamus]

Thanks for the PR. I'm assuming this covers the case where just the body of the PR has changed but not the PR itself. Have you considered possible race conditions if the PR itself was modified during that timelapse and whether that's something you wanted to check for (and maybe do something about)?

I had considered this. The strategy I thought of for this is to abort and "re-queue" the build, however this seemed like more of an extensive change and so I went for this as a lighter-touch change.

[tobie]

So I dug into re-queuing and ended-up with this: #165. LMK what you think.