Add admin setting for SM users allowing non-enforcement of token expiration

From discussion in https://gitlab.com/gitlab-org/gitlab/-/issues/462157#note_1977881817, we'd like to create an admin setting for GitLab SM that removes the expiration enforcement of PAT, PrAT and GrATs A SM admins can optionally enable the setting Require access tokens to have an expiry to require expiration for their tokens. This will only be applicable to net new tokens.

The existing setting max_personal_access_token_lifetime will be moved as a sub-setting within the above option and a value can be set until the parent setting to enforce expiration is disabled.

For users that have not yet migrated to 16.0 (i.e the expires_at haven't been set via the migration) this setting should be default off to reflect the expiration status. For users on 16.0 and above the setting should default to on as expires_at values would already be set via the migration

Revised proposal

Based on the discussion in the thread below and a sync conversation with @ifarkas @hsutor @adil.farrukh we are proposing the following solution to ensure consistency between existing settings around token expiration and the expected behaviour from a user perspective

• require_personal_access_token_expiry Will be an instance level setting for SM. While it will be available on .com as well, it will simply persist in the default enabled state that admins of GitLab.com can modify (though they typically don't). This will control the need for having an expiration for PAT, PrAT and GrAT generated for human accounts (i.e Not service accounts). The description label for the setting will make this clear to the users.
• service_access_tokens_expiration_enforced will stay as an independent setting allowing users to control whether their service account PAT, PrAT or GrAT should have an expiration. Default enabled, this will work individually from require_personal_access_token_expiry and a SM admins or top level group owner can manage it for SA accounts for their instance or group.
• max_personal_access_token_lifetime will be kept as a separate setting and not made a sub-setting as originally proposed as it makes it difficult to reconcile with the SA expiration enforcement setting. It will however add a max day expiration to either of the 2 available settings require_personal_access_token_expiry or service_access_tokens_expiration_enforced if enabled individually for the respective account types.

As an example to understand the behaviour, lets consider the following configuration:

• require_personal_access_token_expiry: enabled
• service_access_tokens_expiration_enforced : disabled
• max_personal_access_token_lifetime: 50 days

A 50 day max expiration is applied to human user PAT/PrAT or GrATs while service account tokens continue as without having any token expiration.