Destroy UpcomingReconciliation record when there is no longer an upcoming reconciliation

What does this MR do and why?

Addresses part of: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3722.

Counterpart MR on CustomersDot: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4140

Destroy the relevant GitlabSubscriptions::UpcomingReconciliation when a reconciliation is no longer going to be performed for the namespace or instance. This resolves an issue where users that cancelled subscriptions would still see upcoming reconciliation notifications on the original reconciliation date.

For .com namespaces:

We introduce a new internal API for the Customers app to call and delete the upcoming reconciliation record.

For self hosted instances:

Destroy the upcoming reconciliation record when we stop receiving a next reconciliation date during the daily SeatLink process.

How to set up and validate locally

Self-Managed

1. On the CustomersDot application, purchase a subscription for a self hosted instance
2. Update the Reconciliation record created in the Customers app to reconcile in 6 days and have exceeded the user count

   reconciliation.update!(user_count: reconciliation.subscription.total_quantity + 10, reconcile_on: 6.days.from_now)

3. Enable seat reconciliation on the subscription in Zuora
4. Upload the license to the local GitLab instance
5. Ensure the instance doesn't think it's .com by disabling namespace plan check

   ApplicationSetting.first.update!(check_namespace_plan: false)

6. Run the Seat Link worker in the GitLab application

   require './spec/support/sidekiq_middleware'
   
   Sidekiq::Testing.inline! do
     HistoricalDataWorker.new.perform
   
     data = Gitlab::SeatLinkData.new
     SyncSeatLinkRequestWorker.perform_async(data.timestamp.iso8601, data.key, data.max_users, data.billable_users_count)
   end

7. Observe the UpcomingReconciliation record has been created
8. Mark the reconciliation as skipped in the CustomersDot app

   reconciliation.update!(skip_reason: :reconciliations_disabled, reconcile_done_at: Time.current)

9. Run the Seat Link worker in the GitLab application
10. Observe the UpcomingReconciliation record has been destroyed

SaaS

1. Ensure the instance thinks it's .com by enabling namespace plan check and setting the Gitlab.com? method to return true

   ApplicationSetting.first.update!(check_namespace_plan: true)

2. Purchase a group subscription for a namespace in the Gitlab application
3. Update the reconciliation to be within the notification period and ensure the plan has synced with Gitlab

   Reconciliation.last.update!(reconcile_on: 6.days.from_now)
   Gitlab::Namespaces::UpdatePlanInfoService.new(Reconciliation.last.order)

4. Add another user to the group on Gitlab so that the seats used has an overage
5. Update the max seats used statistics on Gitlab

   UpdateMaxSeatsUsedForGitlabComSubscriptionsWorker.new.perform

6. Run the upcoming reconciliation notification cron job on customers dot

   require './spec/support/sidekiq.rb'
   
   Sidekiq::Testing.inline! do
     UpcomingReconciliationNotificationCronJob.new.perform
   end

7. Observe the UpcomingReconciliation record has been created in the Gitlab application
8. Call the API to delete the upcoming reconciliation record (this will be done by the customers application later). The access token can be found in the customers dot secrets.yml

   curl --request DELETE \
     --url "http://localhost:3000/api/v4/internal/upcoming_reconciliations?namespace_id=<namespace_id>" \
     --header 'PRIVATE-TOKEN: <admin_access_token>'

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.