WIP: Move access requests into their own table

What does this MR do?

Creates a new access_requests table, removes requested_at from the members table (migrating existing data), and refactors the codebase accordingly.

Are there points in the code the reviewer needs to double check?

It's just the migrations at the moment. Lots of TODOs there. Main point: this seems like it will require downtime.

The migrations only operate on entries FROM members WHERE requested_at IS NOT NULL, so the data migration is not expected to take long - it's thousands, rather than millions, of rows.

Why was this MR needed?

Having inactive memberships in the members table is risky, as naive selects will result in security vulnerabilities.

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

• CHANGELOG entry added
• Documentation created/updated
• API support added
• Tests
  • Added for this feature/bug
  • All builds are passing
• Conform by the merge request performance guides
• Conform by the style guides
• Branch has no merge conflicts with master (if you do - rebase it please)
• Squashed related commits together

What are the relevant issue numbers?

Closes #21906 (closed)