Batch migration to set `OauthAccessToken#expires_in`

What does this MR do and why?

• We enforced OAuth token expiry as a breaking change for 15.0
• We did it 2 steps:
  1. enforced expiring tokens for OAuth applications in !86362 (merged)
  2. run a background migration to set expiry for all existing tokens in !86379 (merged)
• Both changes have been successfully deployed, and the background migration successfully set expiry for all existing tokens.
• However, since then, the number of OAuth tokens without expiry is growing which shouldn't happen.
• This migration is adapted from this previous MR, which was used to add an expiration to all existing OAuth access tokens: !86379 (merged)
• We've discovered 2 areas where new tokens with expires_in: nil were created:
  • Calling OauthAccessToken.new directly does not set a default expires_in. We stopped calling OauthAccessToken.new directly via !105734 (merged)
  • Doorkeeper's refresh token flow will set the expires_in value of any refreshed tokens to match the expires_in value of the token doing the refreshing. This means that any tokens that happened to be refreshed while the previous batch migration was running could have been created with expires_in: nil. This issue was fixed via !107306 (merged)
• Now, re-running the same migration as before should result in zero oauth_access_token records in the DB with expires_in: nil
• Once that is confirmed, we will add a database constraint that ensures this is the case going forward.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.