Setup a retention policy for authentication_events table

https://gitlab.com/gitlab-com/gl-infra/capacity-planning-trackers/gitlab-com/-/issues/2289+ reported a continued increase in authentication_events table, that was added to track sessions created across various auth mechanisms (SAML, LDAP etc).

The table requires a 1 year retention policy setup such that it is vacuumed at intervals. We have also identified that the logs are displayed at https://gitlab.com/-/user_settings/authentication_log which currently has no limits. Switching to 1 year would be a fair tradeoff between displaying important log info, and persistent storage limits

Proposal

We'll introduce a new temporary table that mirrors the authentication_events table's schema. Then we'll write a Sidekiq worker that iterates through all authentication_events, and for each row with created_at < 1.year.ago, in one transaction, move the row to the archive table and delete it from production table.

Steps

Adapted from description of this issue:

First release (archive and deletion)

• Create authentication_events_archive table. (!202447 (merged))
  • Schema exactly mirrors the production authentication_events schema
• Create batched background migration to archive a large initial batch of records (!202447 (merged))
• Enqueue the batched migration only for gitlab.com (!202447 (merged))
• Create a new feature flag archive_authentication_events (#573714)
• Create a Sidekiq worker that archives and deletes rows from authentication_events once per day (scheduled via cron)
  • Does not delete anything if feature flag is disabled which prevents it from running on self-hosted instances
• Enable archive_authentication_events FF to enable daily archiving