Buffer seat overage notifications

What does this MR do and why?

Alternative approach for solving #358080 (closed)

This mostly organizes the existing logic into three main components allowing us to utilize our Sidekiq job deduplication to stage/buffer and deduplicate seat overage notifications. These components are:

1. GitlabSubscriptions::SeatsExceededNotification::QualificationService
   • This contains all logic that determines if we should queue or send a notification.
2. QueueNotificationWorker/QueueNotificationService
   • This is the worker subscribed to the MemberAdd event.
   • We check QualificationService and if the event qualifies, we queue SendNotificationWorker to be performed at some point in the future (currently 12hrs)
3. SendNotificationWorker
   • This is set with scheduled deduplication, so we will only send the notification once per scheduled interval.
   • Since this job is performed in the future, we run the QualificationService again before sending the notification incase things have changed.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

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.