Refresh GitLab Auth Tokens

[nickoferrall]

In GitLab's May 2022 update, they have deprecated non-expiring tokens and are now expiring tokens after two hours: https://northflank.com/blog/supporting-expiring-oauth-access-tokens-for-gitlab

AC

• [ ] Refresh GitLab tokens so that users can still access their GitLab integration two hours after integrating

[nickoferrall]

Current plan:

• after integrating with GitLab, store the token expiration timestamp in Redis
• create a gitlabAuth dataloader that uses our teamMemberIntegrationAuths
• in the dataLoader, get the token's TTL from Redis
• if we're almost at the limit, refresh the token
• upsert the new access token in the teamMemberIntegrationAuth table

[Dschoordsch]

• in the dataLoader, get the token's TTL from Redis

Why would we store the TTL in Redis when the token itself is stored in Postgres? That seems out of place to me.

[nickoferrall]

We could store it in Postgres, but I was thinking Redis because:

• Currently, the TTL is GitLab specific, so adding a migration for teamMemberIntegrationAuths might be overkill
• With Redis, you can set the TTL on the key and then just check whether the key exists. In Postgres, we'd need to store the timestamp and compare it with the current timestamp. Not a big deal, but not as clean as Redis

[nickoferrall]

@Dschoordsch curious to get your thoughts on the above. I created a PR for this yesterday evening: https://github.com/ParabolInc/parabol/pull/6594

If you feel that the TTL needs to live in Postgres, I'll work on the change today.