Changes for executing webhook for 30D and 60D notification email

What does this MR do and why?

#499732 (closed)

Currently we are sending Notification emails for PersonalAccessTokens expiry for three intervals -

1. 60 Days
2. 30 Days
3. 7 Days

But in case of Resource Access Tokens we only execute webhook when notification email is sent at 7 days interval. https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html#project-and-group-access-token-events

Requirement is - User should be able to execute the webhook multiple times event when email notification is sent at 60 days and 30 days interval.

We are providing the user an option to keep the default behaviour of executing webhooks only when 7 days interval email notification is sent but if user enables the setting at Group level or project level, the webhook will be executed at all the intervals including seven days.

In this MR we are adding two settings

1. Group level setting - extended_grat_expiry_webhook_execute - Which is disabled by default
2. Project level setting - extended_prat_expiry_webhook_execute - disabled by default.

We need two settings for two reasons majoryly

1. User can create different webhooks at group and subgroup level, once the event is triggered for Subgroup all the webhooks which belong to the ancestors related to the event are executed. In this MR each group will check the related setting and execute the webhook in case the setting is enabled

For example - Parent Group 1 - has webhook registered for event expiring_access_token SubGroup 1 - also has webhook registerd for event expiring_access_token

Setting for Parent Group1 extended_grat_expiry_webhook_execute is set to false Setting for SubGroup 1 extended_grat_expiry_webhook_execute is set to true

Once the event is triggered when email notification is sent either at 30 days or 60 days interval. Webhook for the SubGroup 1 will be executed since the setting is set to true but Parent Group1 webhook will not be executed since the setting is set to false.

2. Any Project can belong to root namespace and not to any group. So we need to have Project level setting too to handle any such case

In this MR I am introducing following changes

1. Migration for ProjectSetting column
2. Migration for GroupSetting column
3. UI changes for Groups settings
4. Controller changes Groups settings
5. Changes for webhook execution for Groups
6. UI Changes for Project Settings
7. Controller changes for Project
8. Changes for webhook execution for Project

How to set up and validate locally

1. Run bin/rails db:migrate

2. Enable Feature flag from rails console

Feature.enable(extended_expiry_webhook_execution_setting)

1. Enable group setting from UI - <group>/settings/General/Permissions and group features/Extended Group Access Tokens Expiry Webhook execution

1. Create a group access token and set the expiry date to future to somewhat 30 Days or 60 Days away

2. Configure the webhook for group - https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#create-a-webhook

3. Execute ExpiringWorker from the rails console

PersonalAccessTokens::ExpiringWorker.new.perform

Observe webhook getting executed for the token even though the expiry interval is not 7

1. Now create a project access token for the project that belongs to group for which we enabled setting in Step2.
2. Set up a separate webhook for project- https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#create-a-webhook
3. Again Execute ExpiringWorker from the rails console

PersonalAccessTokens::ExpiringWorker.new.perform

1. Observe only parent Group webhook is executed since Project's setting is not set still
2. Now enable Project setting from Settings > Visibility, project features, permissions > Extended Project Access Tokens Expiry Webhook execution
3. Again create a project access token and run ExpiringWorker
4. Observe this time both Group and Project webhooks are executed.

Query Execution Plan We do not have column extended_grat_expiry_webhooks_execute in production yet but I executed the same query with other namespace setting column - product_analytics_enabled. And attaching the query execution plan here -

https://console.postgres.ai/gitlab/gitlab-production-main/sessions/35689/commands/110431

Time: 6.287 ms
  - planning: 2.641 ms
  - execution: 3.646 ms
    - I/O read: 3.478 ms
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 3 (~24.00 KiB) from the buffer pool
  - reads: 2 (~16.00 KiB) from the OS file cache, including disk I/O
  - dirtied: 0
  - writes: 0