Properly update retry_last_ts when hitting the maximum retry interval

[deepbluev7]

This was broken in 1.87 when the maximum retry interval got changed from almost infinite to a week (and made configurable).

fixes #16101

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file. The entry should:
  • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
  • Use markdown where necessary, mostly for code blocks.
  • End with either a period (.) or an exclamation mark (!).
  • Start with a capital letter.
  • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
• Pull request includes a sign off
• Code style is correct
  (run the linters)

[deepbluev7]

Basically the problem is that if the retry ts is older than 8 days, but the retry interval is already 7 days, we would never update the last retry. This solution might cause a few too many writes, but those should only happen if we retry for other reasons, I hope?

[deepbluev7]

Actually, converting this to a draft, since this does not work, if the retry interval in the db is bigger than the new max retry interval and the server never was online in between...

[deepbluev7]

Okay, I think this works, but there where clauses confuses me :D

[deepbluev7]

Grafana dash after those changes at around 12:35:

[MatMaul]

I added a test, and change the fix for something looking more legit to me, since I had trouble understanding exactly how your fix was working @deepbluev7.

[erikjohnston]

Ah, didn't spot that the fix has changed. I think the current fix does work, but equally for clarity I think we should add a clause to the upsert to ensure that we do update the last_retry_ts.