[Feature flag] Enable through_version_manager

# Summary

This issue is to rollout [Order#current_subscription to use version manager](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6094) on CustomersDot production,
that is currently behind the [`through_version_manager`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/185/edit) feature flag.

This is for issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4884

## Owners

- Team: ~"group::provision" 
- Most appropriate Slack channel to reach out to: `#g_provision`
- Best individual to reach out to: @lulalala 
- PM: @courtmeddaugh
- EM: @mlunoe 

## 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

- Rollout Feature for everyone as soon as it's ready

<!-- Which dashboards from https://dashboards.gitlab.net are most relevant? Sentry errors reports can also be useful to review -->

## Testing User/Customer IDs

<!--
List any Customer IDs for Customers that are happy to have this feature turned on early.

Remove if not applicable
-->

## Expectations

### What are we expecting to happen?

No behavior change

### What might happen if this goes wrong?

Reconciliation and SeatLink uses wrong subscription

### What can we monitor to detect problems with this?

- Sentry
- Grafana health score

## 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
- [-] 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 that you or a representative in Fulfillment can be available for at least 2 hours after feature flag updates in production.
  If a different developer will be covering, or an exception is needed, please inform the Fulfillment team in #s_fulfillment_engineering
- [-] Ensure any documentation has been updated
- [-] Announce on [the feature issue](ISSUE LINK) an estimated time this will be enabled on production if applicable
- [-] If the feature might impact the user experience, notify `#s_fulfillment` and potentially `#support_gitlab-com`, as well as your team channel ([more guidance when this is necessary in the dev docs](https://docs.gitlab.com/ee/development/feature_flags/controls.html#communicate-the-change)).

### Global rollout on CustomersDot production

- [x] Confirm the feature flag is enabled on `staging` without incident
- [-] Roll out the feature to targeted testing users first (if applicable)
- [-] If applicable, [incrementally roll out](https://docs.gitlab.com/ee/operations/feature_flags.html#percent-rollout) the feature.
- [-] 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
- [x] Announce on [the feature issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4884) 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] Create a merge request to remove `<feature-flag-name>` 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](LINK TO THE FEATURE FLAG EDIT PAGE)

Story points: 1.0