[Feature flag] Persist Billing Account related data

<!-- Title suggestion: [Feature flag] Enable description of feature -->

# Summary

We are introducing logic that will populate `BillingAccount` and `BillingAccountMembership` as part of https://gitlab.com/groups/gitlab-org/-/epics/8950+ given we are going to iteratively add small bits we want to make sure we update at least all the places listed in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4795+ before start collecting the data in production.

This issue is to rollout the persistence of the data related to `BillingAccount` and `BillingAccountMembership` currently behind the [`account_data_persistence`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/171/edit) feature flag.

## Owners

- Team: ~"group::fulfillment platform" 
- Most appropriate Slack channel to reach out to: `#g_fulfillment_platform`
- Best individual to reach out to: @tyleramos or @vshumilo 
- PM: @mgass1 

## Stakeholders

No other stakeholders.

## The Rollout Plan

Rollout Feature for everyone as soon as it's ready

## Expectations

### What are we expecting to happen?

Customer's associated billing account is kept up to date with `customer.zuora_account_id`.

### What might happen if this goes wrong?

- Disruptive exceptions in the code.

### What can we monitor to detect problems with this?

- Keep an eye on [Sentry](https://sentry.gitlab.net/gitlab/customersgitlabcom/#).
- Check `#s_fulfillment_status` for errors.

## 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) - **Lena: Based on the criteria there is no need for change management issue
  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
- [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
- [x] Announce on [the feature issue](ISSUE LINK) 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: 2.0