When retrying based on `x-ratelimit-reset`, take local time and server time into account

[gr2m]

trafficstars

I've seen the plugin handle the primary rate limit correctly, wait until the provided x-ratelimit-reset time, and then immediately hit the rate limit again. My guess is that local time and server time are out-of-sync. It's something we had to take into account for the timeouts of installation access tokens as well in https://github.com/octokit/auth-app.js.

[gr2m]

A mentee of mine ran into the problem using code that I haven't changed for a long time. It sure feels like something changed: https://github.com/Rutasd/hearted_contributions/issues/1#issuecomment-1668466480

I'll take care of the date sync but also add a few seconds extra buffer

[gr2m]

for reference, this is how we account for time skew in @octokit/auth-app: https://github.com/octokit/auth-app.js/blob/fdfdcc294bc5fc27eeed86d4a3d0915826fdd553/src/hook.ts#L48-L80

[jyasskin]

I also saw the identical Date and x-ratelimit-reset headers (Mon, 23 Oct 2023 21:48:42 GMT and 1698097722) in https://github.com/jyasskin/spec-maintenance/actions/runs/6618851077/job/17978147853. Both clocks are on Github infrastructure, so it's unlikely they're out of sync, although it's possible. https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#exceeding-the-rate-limit says "you should not try your request until after the time specified by the x-ratelimit-reset time" (my emphasis). So we probably ought to add a second to the time. We could also use the date header instead of Date.now(), but that doesn't seem like it was the cause of either of these examples.

[gr2m]

you should not try your request until after the time specified by the x-ratelimit-reset time

I think we should totally add a second. Does not implement the fix described in this issue, but it's much simpler and I think we should do it. 👍🏼