Draft: Update OAuth Access Tokens to have a default expiration

What does this MR do and why?

• This migration is adapted from this previous MR, which was used to add an expiration to all existing OAuth access tokens: !86379 (merged)
• It was later discovered that there were still new OauthAccessTokens being created without an expiration because calling OauthAccessToken.new directly does not set a default expires_in.
• Doorkeeper controllers will set the ttl to Doorkeeper.confg.access_tokens_expires_in by calling Doorkeeper::OAuth::CientCredentials::Issuer.new.create
• Calling OauthAccessToken.new is problematic because it will not set a default expiration. The good news is that, as far as I can tell, we only do that in ee/app/services/gitlab_subscriptions/create_service.rb.
• There are currently ~14k oauth access tokens on prod that do not have an expiration and are not revoked
• Almost all of those 14k tokens are from one OAuth application: "GitLab Subscription Portal" (customers.gitlab.com) which is addressed via !105734 (merged).
• Via this MR, we will ensure that all existing OAuthAccessTokens have an expiration value.

Migration

% rake db:migrate:main VERSION=20221202002124
main: == 20221202002124 ScheduleExpireOAuthTokensCleanup: migrating =================
main: == 20221202002124 ScheduleExpireOAuthTokensCleanup: migrated (0.0444s) ========

% rake db:rollback:main VERSION=20221202002124
main: == 20221202002124 ScheduleExpireOAuthTokensCleanup: reverting =================
main: == 20221202002124 ScheduleExpireOAuthTokensCleanup: reverted (0.0089s) ========

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.