AO3-7249 Track past emails and usernames via a separate table

[Kiyazz]

Pull Request Checklist

• Have you read "How to write the perfect pull request"?
• Have you read the contributing guidelines?
• Have you added tests for any changed functionality?
• Have you added the Jira issue number
  as the first thing in your pull request title (e.g. AO3-1234 Fix thing)
• Do you have fewer than 5 pull requests already open? If not, please wait
  until they are reviewed and merged before creating new pull requests.

Issue

https://otwarchive.atlassian.net/browse/AO3-7249

Purpose

This PR adds new tables for storing old usernames and emails to prevent needing to query the audits table, which can be large for old accounts and doesn't easily support an index. This allows cleaning up the audits table and increasing performance of querying old credentials

References

AO3-7216 is supposed to be reverted as part of this PR

Credit

kiyazz (he/him)

[Kiyazz]

Right now the PR has 2 parts of 3 from what's required. The last part asks for reverting a previous PR which i'm unsure if I should do inside a commit here

[brianjaustin]

We usually don't mind reverting a previous PR as part of a newer, larger one. However, we did end up splitting that part out into a separate ticket (https://otwarchive.atlassian.net/browse/AO3-7251) for safety (writing and reading in the same PR is a recipe for a messy deploy), so good instinct there 😅

Some comments for you when you have time

[Kiyazz]

Right now I use the old name + timestamp to uniquely identify a change. This works in testing but isn't guaranteed to work in production because audit and table entry timestamps don't have to match. Actual unique identifying would take an extra database table

[brianjaustin]

audit and table entry timestamps don't have to match

This might require ruby instead of SQL (which means a small possibility of race conditions, which is fine), but what about checking old value + timestamp within a resolution of 60 seconds? That way, we can account for a delay between the change and callback execution in the vast majority of cases

[Kiyazz]

That's easily possible to do in SQL. Since it's batching by user, no race conditions are possible either.

[brianjaustin]

Thanks!