Rework how email verification works

[sandhose]

This completely redesigns how email verification works.

Fixes #3112
Fixes #2881
Helps with #1505

This is meant to be reviewed commit by commit

As per the task list bellow, it's missing a few little things, but those are details that can be tackled later, and I'll open individual issues for them.

Tasks

Preview Give feedback

1. Remove the concept of 'primary email' and unverified emails
2. Add a new separate 'email authentication' with codes
3. Hookup the react frontend to the new email authentications
4. Stop requiring a valid email during authorisation flows
5. Store registration flows in the database
6. Remove the old email add/verification screens
7. Check for email uniqueness on registration
8. Make sure running registration flows are attached to the browser with a signed cookie
9. Screen to choose a display name
10. Check for username uniqueness and email uniqueness again when completing the registration
11. Delete all the existing unverified emails
12. Have a proper error message on duplicate emails and on wrong email verification code
13. Button to retry the email verification in the registration flow
14. Use the new user registrations in the upstream OAuth 2.0 registrations
15. Config options to control what's required

Quick screen recording on how it looks:

output.mp4

[cloudflare-workers-and-pages]

Deploying matrix-authentication-service-docs with    Cloudflare Pages

Latest commit:	8d50088
Status:	✅  Deploy successful!
Preview URL:	https://1c820446.matrix-authentication-service-docs.pages.dev
Branch Preview URL:	https://quenting-optional-email.matrix-authentication-service-docs.pages.dev

View logs

[reivilibre]

This is a chunky one! But in principle I'm happy with most of what's here.

I have left .s on things that looked like they'd be worth getting back to and wasn't sure if you would have done in later commits, but now I can't easily see those comments again because the diff is too big it won't load nicely :D.

I'd like to more carefully consider the security and privacy aspects of the registration flow; I've spotted some issues but am not sure there aren't others.

[sandhose]

@reivilibre I think I've gone through all your comments.

I've introduced rate limiting and made it so that we disclose that the email is already in use only after verifying. I'm waiting for proper design for those screens, but what I have in the meantime is probably fine, and can be adjusted later.

[reivilibre]

maybe so, but this is likely good enough. I don't think non-ASCII e-mail localparts are common at all? I have never seen one in the real-world.

To be useful, we'd have to assume the recipient server is also doing casefolding transformations. I am sceptical.

All in all, happy with just lowercasing

[sandhose]

I copied that from you 😇

https://github.com/element-hq/matrix-authentication-service/blame/ef077d0e51c68ffac547c393639e8d1d49018c7a/crates/handlers/src/rate_limit.rs#L189-L191

[reivilibre]

if it's not too hard to do, I'd be tempted to add a button along the lines of 'Forgot your password? Click here to recover your account' and it would be as though the user submitted the account recovery form — i.e. it would send the recovery e-mail immediately

If the user logged in with a upstream provider, maybe we could remind them which one they used, such as 'You can log in to your account using Google'

[reivilibre]

(if preferred, could also defer this to an issue for later)

[sandhose]

I've asked design to have a look, will iterate on that later