chore: migrate FailedAuthRequest to pg

[jordanh]

Description

Resolves #9499

Testing scenarios

• Attempt to login with bad password
  • Check that attempts are being logged to FailedAuthRequest table in PG
  • Validate exceptions do not occur

Final checklist

• I checked the code review guidelines
• I have added Metrics Representative as reviewer(s) if my PR invovles metrics/data/analytics related changes
• I have performed a self-review of my code, the same way I'd do it for any other team member
• I have tested all cases I listed in the testing scenarios and I haven't found any issues or regressions
• Whenever I took a non-obvious choice I added a comment explaining why I did it this way
• I added the label Skip Maintainer Review Indicating the PR only requires reviewer review and can be merged right after it's approved if the PR introduces only minor changes, does not contain any architectural changes or does not introduce any new patterns and I think one review is sufficient'
• PR title is human readable and could be used in changelog

[jordanh]

id now managed by Postgres

[jordanh]

This is an equivalent query to what we were doing with Rethink. Just 1 trip and returns an object with these two fields. While the Kysely is pretty readable, here's what the query compiles to:

WITH "byAccount" AS (
    SELECT
        COUNT("id") AS "attempts"
    FROM
        "FailedAuthRequest"
    WHERE
        "ip" = $1
        AND "email" = $2
        AND "time" >= $3
),
"byTime" AS (
    SELECT
        COUNT("id") AS "attempts"
    FROM
        "FailedAuthRequest"
    WHERE
        "ip" = $4
        AND "time" >= $5
)
SELECT
    "byAccount"."attempts" >= $6 AS "failOnAccount",
    "byTime"."attempts" >= $7 AS "failOnTime"
FROM
    "byAccount",
    "byTime";

[Dschoordsch]

-1 this should be nextBatch.slice(0, lastMatchingTime + 1), see your scheduled job PR. I also think we don't need to have this migration at all. Because it's bound to only 1 day, if an attacker gets double the amount of tries for 1 day, that shouldn't be too risky.

[jordanh]

@Dschoordsch, actually it should nextBatch.slice(0, lastMatchingTime)! When I first read this code, I thought that +1 was correct...then I did another migration and ran into some mysteriously missing rows. When I stepped through with a debugger I caught what was going on. See:

#9502 (comment)

[jordanh]

Indeed this is an ephemeral table. I would be happy to nuke this migration if you come back with a +1 comment

[jordanh]

@Dschoordsch updated with your review comments.

Note: I rebased to master to catch latest migration from other branches

[Dschoordsch]

@jordanh I just noticed what you wrote. Please re-request review next time (by pressing the refresh button next to my changes requested). I only regularly check the view https://github.com/ParabolInc/parabol/pulls?q=is%3Apr+is%3Aopen+user-review-requested%3A%40me and might miss this otherwise.