[Feature flag] Enable block_seat_overage_notification

# Summary

<!-- Short description of what the feature is about and link to relevant other issues. -->

This issue is to rollout and cleanup [a feature to prevent enqueuing `SendSeatOverageNotificationJob` for certain namespaces](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4934) in CustomersDot production, that is currently behind the [`block_seat_overage_notification`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/165/edit) feature flag.

## Owners

- Team: ~"group::billing and subscription management" 
- Most appropriate Slack channel to reach out to: `#g_billing_and_subscription_management`
- Best individual to reach out to: @jhyson @tyleramos
- PM: @tgolubeva 

## Stakeholders

<!--
Are there any other stages or teams involved that need to be kept in the loop?

- GITLAB_HANDLE of a PM
- The Support Team
- The Delivery Team
-->

## The Rollout Plan

- This feature was rolled out immediately in production to mitigate the issue that was bloating [our Sidekiq queues](https://customers.gitlab.com/sidekiq/).

## Expectations

### What are we expecting to happen?

When enabled, this feature will prevent the `SendSeatOverageNotificationJob` from being enqueued for specific GitLab namespace ids (currently just `10782951`).  See https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5582 for more info.

### What might happen if this goes wrong?

The feature flag should make it easier to toggle this blocking logic.  If it doesn't work, it's possible that the `SendSeatOverageNotificationJob` doesn't get blocked properly for the specified namespace.

### What can we monitor to detect problems with this?

We can monitor problems [in Sentry](https://sentry.gitlab.net/gitlab/customersgitlabcom/) or [in Sidekiq](https://customers.gitlab.com/sidekiq/).

## Rollout Steps

### Rollout on non-production environments

- [x] Ensure that the feature MRs have been deployed to non-production environments, i.e. `customers-staging`.
- [x] Consider announcing that the flag will be enabled to potentially impacted groups, e.g. `#s_fulfillment_engineering`
- [x] Enable the feature globally on non-production environments by applying the appropriate environment, e.g. `customers-staging` and `customers-development`.
- [x] Notify the Software Engineers in Test (SETs) for Fulfillment via Slack and in a comment in this issue when enabling a feature flag in `customers-staging` as it can impact the QA pipeline.
- [x] Verify that the feature works as expected. Posting the QA result in this issue is preferable.

### Preparation before production rollout

- [x] Ensure that the feature MRs have been deployed to production
- [x] Check if the feature flag change needs to be accompanied with a
  [change management issue](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/#feature-flags-and-the-change-management-process).
  Cross link the issue here if it does.
- [x] Ensure any documentation has been updated
- [x] Announce on [the feature issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4934) an estimated time this will be enabled on production if applicable

### Global rollout on CustomersDot production

- [x] Confirm the feature flag is enabled on `staging` without incident
- [x] Roll out the feature to targeted testing users first (if applicable)
- [x] If applicable, [incrementally roll out](https://docs.gitlab.com/ee/operations/feature_flags.html#percent-rollout) the feature.
- [x] Verify the change has the desired outcome with the limited rollout before enabling the feature globally on production.
- [x] Enable the feature globally on production environment
- [~] Announce on [the feature issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4934) that the feature has been globally enabled.
- [x] Wait for [at least one day for the verification term](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release).

### Release the feature

After the feature has been [deemed stable](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release),
the clean up should be done as soon as possible to permanently enable the feature and reduce complexity in the codebase.

<!-- The checklist here is to help stakeholders keep track of the feature flag status -->
- [x] Ensure https://gitlab.com/gitlab-org/gitlab/-/issues/358080 has been resolved before removing the feature flagged code.
- [x] Create a merge request to remove `block_seat_overage_notification` feature flag
  - [x] Remove all references to the feature flag from the codebase
- [x] Ensure that the cleanup MR has been deployed to both staging and production
- [x] Disable the feature flag via the [CustomersDot dashboard](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags)
- [x] Ensure production environment is still working as expected
- [x] Remove the Unleash feature flag from the [CustomersDot dashboard](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags)
- [x] Close this rollout issue.

## Rollback Steps

- [ ] This feature can be disabled by performing the following actions:
  - [ ] Disable the Unleash flag on the [feature flag page](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/165/edit)

Story points: 1.0