Change: check expiration of legacy tokens, reject if necessary

[shreddedbacon]

General Checklist

• Affected Issues have been mentioned in the Closing issues section
• Documentation has been written/updated
• PR title is ready for inclusion in changelog

Database Migrations

• If your PR contains a database migation, it MUST be the latest in date order alphabetically

As we look to phase out the usage of legacy tokens, we need to be able to reject long lived or non-expiring legacy tokens initially.
This introduces two new environment variables that can be set in the API.

• LEGACY_EXPIRY_MAX (default 3600s) - This is the maximum expiry that can be allowed to interact with the API
• LEGACY_EXPIRY_REJECT (default false) - This is what controls if a legacy token is rejected based on the checks

If a legacy token has the exp field, the remaining duration of the token is calculated against the iss timestamp. If this duration is greater than the LEGACY_EXPIRY_MAX, then depending on the LEGACY_EXPIRY_REJECT setting, it will log, or log and reject the request.

If there is no exp field on the token, then depending on the LEGACY_EXPIRY_REJECT setting, it will log, or log and reject the request.

[rocketeerbkw]

Discussed in meeting, looks good 👍

[tobybellwood]

Approving additional logic to set internal tokens to 60sec