Zuora Central Sandbox Refresh procedures

### Problem

Last time [Zuora Central Sandbox was refreshed](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/477), Fulfillment engineers were blocked from using CustomersDot stg while the refresh was happening, but even ran into to problems after the refresh was completed.  For instance, many engineers needed to request Zuora User access again to be able to log into the [Zuora web app](https://test.zuora.com/).  ~"Enterprise Applications" apps is already working on improving the refresh process by putting together [this playbook of refresh steps](https://docs.google.com/document/d/1smfh7LnmKZYtQ5c9GfHxrhs5-7yUkIJQ4N1fywjNMq4/edit).

Another common problem encountered by people testing in CustomersDot stg after the refresh was the inability to make purchases ([example 1](https://gitlab.com/gitlab-org/gitlab/-/issues/327896#note_808722682), [example 2](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/477#note_807833598)).  This was due to the fact that Customers in CDot stg had `zuora_account_id`s that no longer referenced accounts in Zuora Central Sandbox post refresh.  We are introducing a rake task in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4229 which will clear these orphaned `zuora_account_ids` from CDot stg.

This issue is aimed at identifying any other ways we can improve our post-refresh steps as it pertains to CustomersDot.  Are there any other models that should be updated or cleared?  Here are some thoughts I had, but @fulfillment-group/be please offer up others you might have:

- Instead of simply clearing the `zuora_account_id` for customers, would there be value in truncating the entire `customers` table?  People using CDot stg could simply sign up for new customer accounts to avoid confusion.
- Consider truncating the `orders` table in CDot.  Given that `orders` is strongly tied to Zuora, this table is largely broken when Zuora is refreshed.  Orders with references to `zuora_subscription_name` and `zuora_subscription_id` would be broken.  Should we just start from a clean slate?  In fact, we risk running into collisions if we don't rectify this.

These are just a few idea to start us off.  Please feel free to add to this list or add your thoughts.

### Proposal

Create a rake task to truncate DB tables affected by the Zuora refresh.  This might be as simple as using the following command to truncate a list of tables:

```
ActiveRecord::Base.connection.truncate_tables([:table1_name, :table2_name])
```

This is a list of tables we could consider not truncating:

* `admins`
* `customers`: we will clear the zuora_account_ids that no longer match using a separate rake task
* `features`: to have the correct states of flipper feature flags after the refresh
* `feature_gates`
* `schema_migrations`
* `zuora_user_with_hosts`
* `coupons`: Check with @rcobb if this can/should be truncated
* `leads`: Check with `@a_akgun` if this can/should be truncated

We could include `local_records` in the list of tables to truncate but we'd need to recreate this data by [running the following command](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/f293ff2309025232e67d51c95171a8150cbf61e3/README.md#update-product-information): `IronBank::LocalRecords.export`.

Story points: 3.0