[Feature flag] Rollout redirect for /plans page

# Summary

<!-- Short description of what the feature is about and link to relevant other issues. -->

This issue is to rollout [Remove the CustomersDot plans page and direct users to the marketing pricing page](https://gitlab.com/groups/gitlab-org/-/epics/6806) on CustomersDot production,
that is currently behind the [`redirect_plans_page`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/108/edit) feature flag.

## Owners

- Team: Purchase
- Most appropriate Slack channel to reach out to: `#g_purchase`
- Best individual to reach out to: @dzubova
- 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

- 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 -->

## Expectations

### What are we expecting to happen?

What happens when user reaches [https://customers.gitlab.com/plans](https://ustomers.gitlab.com/plans)?

Independently from login status users will be redirected to [https://customers.gitlab.com/](https://customers.gitlab.com/)

What happens when user reaches [https://customers.gitlab.com/](https://customers.gitlab.com/)?

| x | Before | After |
| ------ | ------ | ------ |
| Case 1: User is logged in | Redirect to `/subscription` page | Render subscription list on the root page (no redirect) |
| Case 2: User is not logged in | Redirect to `/plans` page | Redirect to `/customer/sign_in`, when credentials provided - see above :arrow_up: |
| Case 3: Admin is logged in and impersonating user | Redirect to `/subscription` page (for impersonated user) | Render subscription list on the root page (for impersonated user) |
| Case 4: Admin is logged in | Redirect to `/plans` page | Redirect to `/customer/sign_in` |
| Case 5: New user is logged in (no subscriptions before) | Redirect to `/plans` page | Sees empty state  with 2 buttons on root page |

### What might happen if this goes wrong?

If we receive a feedback about problems with log in or redirect problems we should immediately rollback the FF

### What can we monitor to detect problems with this?

<!-- Which dashboards from https://dashboards.gitlab.net are most relevant? -->

- [#s_fulfillment_status](https://gitlab.slack.com/archives/CL7SX4N86)
- [Sentry](https://sentry.gitlab.net/gitlab/customersgitlabcom/?query=is%3Aunresolved)

## 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] 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 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
- [x] Ensure any documentation has been updated
- [x] Announce on [the feature issue](ISSUE LINK) an estimated time this will be enabled on production if applicable
- [x] 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 epic](https://gitlab.com/groups/gitlab-org/-/epics/6806) 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 `redirect_plans_page` feature flag https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4124
  - [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