WPB-22969: migrate password-reset to PostGreSQL

[blackheaven]

https://wearezeta.atlassian.net/browse/WPB-22969

Checklist

• Add a new entry in an appropriate subdirectory of changelog.d
• Read and follow the PR guidelines

[akshaymankar]

We could also check code here.

[akshaymankar]

I think we should try to do a write in in every step and try to read it in the next step again. This way we're also testing the writes from all 3 interpreters.

[akshaymankar]

Also we need some tests to make sure edge cases of TTL are dealt with correctly.

[akshaymankar]

Suggested change

	"user" uuid NOT NULL,
	user_id uuid NOT NULL,

This way it is easier to detect issues in queries. I'm trying to avoid anything called "user" in postgresql because they don't error until parsing the results.

[akshaymankar]

This is an unused function, feel free to delete it.

[blackheaven]

Addressed the review feedback (rebased onto current develop, squashed to one commit 518acee061):

• Column rename: password_reset."user" → user_id in the migration, the Hasql statements, and postgres-schema.sql.
• genPhoneCode: removed from the Postgres module's export list (kept as a non-exported local so GeneratePhoneCode stays total); the dual-write interpreter now delegates phone-code generation to the Cassandra interpreter. Note the whole phone-reset path is dead (no production callsite, resetPasswordImpl rejects phone identity) — removing it entirely (effect constructor + both copies) could be a follow-up cutover if preferred.
• Integration test rewritten: each phase now writes with a fresh user (reset keys are per-user; a second reset is a silent no-op) and the next phase reads it back — covering writes of all three interpreters. The Postgres phase also checks the worker backfilled the Cassandra-only row, completes the dual-write flow, and exercises the retry edge cases: wrong codes decrement (3→2→1), the third wrong attempt deletes the row, after which even the correct code is rejected and the password is unchanged.
• Also fixed a tuple-arity compile error in BackgroundWorker.hs (the cleanup 10-way Concurrently tuple had a 9-slot constructor) that was failing wire-server-compile-nix, and a copy-paste in the developer docs cutover example (passwordReset: cassandra → postgresql in step 3).

Known deviation worth a look: the backfill worker upserts rows without the per-row exclusive migration lock that the user/domainRegistration/teamFeatures/conversationCodes migrations use, so a row consumed (reset completed / invalidated) between the worker's Cassandra read and Postgres write could be re-inserted with a fresh expiry. Narrow window, but it deviates from the sibling migrations' locking pattern — happy to add withExclusiveMigrationLockAndTimeout + dual-write lock serialization if you'd rather match them.

[akshaymankar]

genPhoneCode: removed from the Postgres module's export list (kept as a non-exported local so GeneratePhoneCode stays total); the dual-write interpreter now delegates phone-code generation to the Cassandra interpreter. Note the whole phone-reset path is dead (no production callsite, resetPasswordImpl rejects phone identity) — removing it entirely (effect constructor + both copies) could be a follow-up cutover if preferred.

I meant we can delete it from the effect itself since there are no call sites.
But it was a nit anyway, so its ok if you merge this without.

[akshaymankar]

Unless I'm missing something, why does the waiting need to be explicitly bound? This is the same right?:

Suggested change

	initiateReset domain >>= \u3' -> do
	waitForMigration domain counterName
	pure u3'
	u3 <- initiateReset domain
	waitForMigration domain counterName
	pure u3