giseldo/neodataset huggingface dataset:
Create BillingAccount and BillingAccountMembership after purchase

### Proposal

The `SubscribeService` and `Zuora::Orders::PostCreationService` should be updated to create a `BillingAccount` and `BillingAccountMembership` at the same time `zuora_account_id` is set on the `Customer` (to be renamed `User`).

#### Feature flag

This logic will be feature flagged in the short term using [the `:account_data_persistence` flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/171/edit).  Here is the rollout issue for it: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5060+.   Once we confirm the data is being created as expected and doesn't have any negative effects with the existing creation behavior, we will remove this feature flag.

As this is just creating data in the new models but not using it yet, we shouldn't need to use the `:account_data_structure` [feature flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/160/edit) for this logic.  Eventually, the code setting `customer.zuora_account_id` will be removed but for now both will be set.  This will allow us to roll out changes more efficiently without worry of breaking existing functionality.

### Delivery plan
- [X] Restrict the validations in `BillingAccountMembership` to allow a single account per `Customer`: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5622
- [x] Create a service that given a customer will update (if necessary) the `BillingAccount` and `BillingAccountMembership` records to reflect the same association the customer is holding: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5660

Plug in the service in the places the customer's `zuora_account_id` set / updated?
- [x] FindOrCreateCustomerService: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5807
- [x] SubscribeService: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5807
- [x] Zuora::Orders::PostSubscriptionCreationService: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5810
- [x] `clear_missing_zuora_account_ids` task: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5811
- [x] :exclamation: Rails Admin allows the update to the customer `zuora_account_id`, there is no code in CDot for this as this update uses the RailsAdmin default logic. Make sure the BillingAccount and BillingAccountMemberships are properly updated base on that: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5832
- [x] Create an issue for ~QA pointing to the service so the associated objects are created in the QA context as well: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5128
  - PostZuoraRefreshTask
  - OrderApiClient
  - QA::Resource::Subscription

Story points: 3.0
Introduce a feature flag for using new Account structure

### Proposal

To deliver features more efficiently and safely, let's introduce a feature flag that can be used to gate the new logic for using Accounts and AccountMemberships.  The feature flag could be named something like `account_data_structure` but open to other suggestions.  When the flag is enabled, the new data structure would be used, otherwise continue to use the old relationships.  Even when the flag is disabled though, we could start populating Accounts and Account Memberships to get into a "compatibility mode" where we could easily switch the flag on and off as needed.

TODOs:

- [x] Create the [feature flag in CustomersDot project](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags): [account_data_structure](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/160/edit) created.
- [x] Create an issue to rollout this feature flag and add it to [the epic](https://gitlab.com/groups/gitlab-org/-/epics/8331): https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4867+

Story points: 1.0
Create AccountMembership model

### Problem

CustomersDot needs a model that represents a `Customer`'s membership to an `Account`.  This would be similar, but not a 1:1 mapping to a Zuora Contact.

### Proposal

Create migration and model for `AccountMembership` which represents a `Customer` ability to manage an `Account` (Zuora Billing Account).

Attributes to consider for model:

* id
* customer_id
* account_id

The relationships created in this join table will be informed by Zuora Contact data, typically received via Zuora Callouts.  When processing callouts or after a purchase is made in CustomersDot, the `AccountMembership` may be created as a result.  This will be implemented in later issues.

Story points: 2.0
Create Account model

### Problem

CustomersDot needs a model that represents a Zuora Customer Account.

### Proposal

Create migration and model for `Account` that maps 1:1 with a Zuora Customer Account.

Attributes to consider for model:
- `id`
- `name` (e.g. Customer.company_name)
- `zuora_account_id`
- `salesforce_account_id`

Other attributes to consider:
- `company_size`
   - This may not need to be persisted on Account as it is currently only used when creating the Salesforce Account when creating a subscription via `SubscriptionManagerService`.  I don't think it is needed for future purchases and therefore probably does not need to be synced.
- `vat_code`
   - This may not need to be persisted on Account as it is currently only used in `SubscribeService` or `Zuora::Orders::Entities::NewAccount` before a new account is created.  I don't think it is needed for future purchases and therefore probably does not need to be synced.
- `billable`
   - This attribute probably makes more sense at the `Customer` or `AccountMembership` level, but may not make sense as currently implemented.  It's used only to determine which customers should receive a welcome email.  This may require a follow-up issue, perhaps not part of this epic.
- `login_activated`
   - This attribute probably makes more sense at the `Customer` or `AccountMembership` level, but may not make sense as currently implemented.  When enabled, this attribute prevents access to CustomersDot.  It is set when a Zuora Callout is processed and a subscription is determined to be managed by a reseller.  This may require a follow-up issue, perhaps not part of this epic.

It might be a good idea to review [the latest `schema.rb`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/db/schema.rb#L112) to make sure all appropriate Customer attributes have been considered for the Account model.

We are leaning towards very light duplication of data that exists in Zuora, and rely on fetching from Zuora when needed.  We will revisit caching in later iterations, but it probably makes sense to store Account `name` and `salesforce_account_id` locally on this table given they will be used frequently.  This means we will need to keep this model in sync with Zuora, which will be implemented in a later issue.

Story points: 2.0
Consolidate subscription state finding logic

### Problem

For a few of the issues in https://gitlab.com/groups/gitlab-org/-/epics/8402, new logic was introduced in CustomersDot to find subscription state.  This new logic was introduced in [the `Subscriptions::VersionManager` class](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/647dcf59d97e50410274960ab0c847e24b7097ab/app/services/subscriptions/version_manager.rb), used in [the `Subscription#previous_subscription` method](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/bf2057bd9b9e6dcadbcdff3e0ad43fb4b9d65d43/app/models/subscription.rb#L214) as well as a handful of other places.

There are a few other places, such as the ones below, where subscription state is determined for fetching the current subscription or future versions.

- [`Subscription#current_subscription`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/bf2057bd9b9e6dcadbcdff3e0ad43fb4b9d65d43/app/models/subscription.rb#L48)
- [`Subscription#subscription_on`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/bf2057bd9b9e6dcadbcdff3e0ad43fb4b9d65d43/app/models/subscription.rb#L52)
- [`SubscriptionFutureVersionFinder`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/4e6b41d7a311ca7ed54f6a9174cec0cb88ceec64/lib/subscription_future_version_finder.rb#L3) (this is used in for the cloud licensing and seat link)

### Proposal

Let's investigate whether the new class `Subscriptions::VersionManger` can be used for the cases above, and consolidate our subscription state logic.

Story points: 3.0
Upgrade Rails to 7

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

[In the light of freezing Rails bug fixes for 6.1 releases](https://rubyonrails.org/2022/9/9/Rails-7-0-4-6-1-7-6-0-6-have-been-released), only security fixes will be landed, we should migrate to Rails 7 to keep our version up to date.


BTW: Rails 7 has more support, for example: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5678#note_1146728976
```
        # Rails 6 `upsert` does not support `:update_only` keyword argument. Rails 7 support `:update_only`.
        # After upgrade to Rails 7, there is no need to query `existing record's created_at`. It could simplify to:
        # LocalRecord.upsert({ name: resource, csv: csv, created_at: current_time, updated_at: current_time },
        #                      unique_by: :name, update_only: [:csv, :updated_at])

```

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Add additional checks in RenewSubscription order action

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

As observed in this [comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5397#note_1094164054), if `params = { auto_renew: false, renew: true }`, AmendSubscriptionService code will only generate `::Amendment::Types::TERMS_AND_CONDITIONS`.

However, `ActionTypesGenerator` will generate both actions: `:renew_subscription` and `:terms_and_conditions`.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Update `check_renewal` in `ActionTypesGenerator` to check for auto renewal and adding new product:

```ruby
def check_renewal
  return unless renewing?
  return if auto_renew_amendment?
  return if adding_new_product?

  actions << :renew_subscription
  actions << :update_product if eoa_starter_bronze_uplift_qualified?
end
```

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Add application instrumentation category

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

'Application instrumentation' category was [recently added](https://gitlab.com/gitlab-com/www-gitlab-com/raw/master/data/stages.yml), it needs to be added to feature category config.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Add warning in Danger if a mailer preview is skipped

## Proposal

- [x] Add previews for any mailers that don't already have one
- [x] Add a warning to [the mailers Dangerfile](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/f8315c9636beef4f2c9baf0a6537f2db91fd325a/danger/mailers/Dangerfile), `mailers/Dangerfile`, to remind people to add a mailer preview if it's not in the MR.

## Follow-up

The following discussion from !5396 should be addressed:

- [ ] @cwiesner started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5396#note_1093158284):  (+1 comment)

    > **question (non-blocking):** I wonder if it makes sense to add some checks to ensure we have a preview available for every mail :thinking:

Story points: 1.0
Determine TERMS_AND_CONDITIONS order action using Orders API

### Problem

Use `ActionTypeGenerator` to determine when a request pertains to updating `TERMS_AND_CONDITIONS` of a subscription.

### Proposal

![Amendment_Manager_Service](/uploads/0d268933ceafe24643b111892095c38d/Amendment_Manager_Service.png)

In this issue, we address (1), (2) and (3) for 'TERMS_AND_CONDITIONS' functionality in the following ways:

(1) Add method `#check_terms_and_conditions` to `Orders::Amendment::ActionTypesGenerator` (see `#check_renewal` for implementation structure). The method returns based on the `params` whether a product is being added to subscription. Use existing logic from `AmendSubscriptionService`.

(2) Add method `#terms_and_conditions` to `Zuora::Orders::FeatureAvailability`. This checks if `Unleash.enabled?(:use_orders_api_terms_and_conditions_workflow)` is enabled. Add `terms_and_conditions` to `SUPPORTED_TYPES` constant

(3) Create validator `Zuora::Orders::Amendment::Validators::TermsAndConditions`. Implement `#validate` method that validates if the request for updating terms and conditions is valid. (see `Renewal validator` for implementation structure). Use existing validation logic from `AmendSubscriptionService`. If no validation is present, the validator can return an empty array.

Create FF `use_orders_api_terms_and_conditions_workflow`.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Set default payment before an upgrade

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

Before an upgrade (adding new and removing existing main product), the [default payment method is updated](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/34a6597b6ae6e3b9bd304a7e83db7847c28f0939/app/services/amendment_base_service.rb#L217).

We need a way to incorporate this change when upgrading using Orders API.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

One option is to set the default payment in the [`PreCreationService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/34a6597b6ae6e3b9bd304a7e83db7847c28f0939/app/services/zuora/orders/pre_creation_service.rb).

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Remove obsolete worker CreateAmendmentWorker

### Problem

It appears that as of https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5064, the `CreateAmendmentWorker` is no longer used within CustomersDot.  It was previously used in the `billingRateUpdateJob` but this was removed in favor of the renewal capabilities of the `AutoRenewJob`.

### Proposal

Let's remove the obsolete worker, `CreateAmendmentWorker`, and its related code.

Story points: 1.0
Change type of `actions` from Array to Set

The following discussion from !5354 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5354#note_1086797196):  (+1 comment)

    > **Suggestion (non-blocking):** I wonder if we made `actions` a [Set](https://ruby-doc.org/stdlib-2.7.6/libdoc/set/rdoc/Set.html) instead of an Array, if that would be slightly more efficient.  It would eliminate duplicates so we wouldn't need to call `.uniq` here.  WDYT?
    > 
    > This could be in a different MR if you like the suggestion.

Story points: 1.0
Exclude unsactioned region on GitLab.com purchase page

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

Background: https://gitlab.com/gitlab-com/legal-and-compliance/-/issues/1024

### Problem


On the country pick list, "Ukraine" specifically excludes "the Crimea Region" but should be updated to exclude "the Crimea, Donetsk, and Luhansk regions"

![image](/uploads/2167f351b27ad5d728e89f92572fa575/image.png)

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Exclude "the Crimea, Donetsk, and Luhansk regions"

### Result

Country list is compliant

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Business driven validation for order actions

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

In addition to validating individual order action types, there are other complex, business driven validations such as [validating an upgrade](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d2d6b0627183cb23baa6b296d76c3718ae7b56b5/app/services/amendment_base_service.rb#L215) and so on.

This kind of validation most often involves more than one order action type.

![CamScanner_09-01-2022_16.19_1](/uploads/2ae42e10e6fae86e5e0307d768b8ef53/CamScanner_09-01-2022_16.19_1.jpg)

The purpose of this issue is to add ability to validate the business driven validations.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

There are at least two ways we can approach it:

- have all the complex use cases in a single file with separate methods OR,
- have a separate class for each of them

TBD.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Use Orders API for Plan upgrade workflow

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

When upgrading a plan (for e.g. from `Premium` to `Ultimate`), [`subscription_upgrades`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/58b903bd713166e58c21b469779859320e2fc10b/config/routes.rb#L102) endpoint is used to preview and perform the upgrade.

There are specifically two Order action types involved: Add a product and Remove a product.

This issue pertains with using Orders API to perform the upgrade.

Related to https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5335#note_1085605708

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Investigate: activation code error received for unknown reason

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem
Customer received a generic error while trying to apply a cloud license activation code. Details:
* Customer had seat overages, but paid for them as true-ups. However they were applied as two different line items. Was the system maybe not recognizing that all true-ups were paid for?
* They first tried to apply the activation code prior to the subscription start date of the renewal; this is when the error occurred. Once they tried on the first day, they were successful in activating. Could the date be a factor?

Supporting material:
* Full context in Slack thread: https://gitlab.slack.com/archives/CMJ8JR0RH/p1661547828336769
* Zendesk Ticket link (includes screenshot of customer admin view): https://gitlab.zendesk.com/agent/tickets/318851

### Ask
* Investigate what caused this error to occur.
* Determine how this can be prevented in the future - do we need any changes, or was this a one-off situation?

### Resolution
![image](/uploads/4927d71ef63cd2929be891a581037175/image.png)

Story points: 5.0
Take care of `app/jobs/zuora` classes (Follow-up from "Add feature categories to job classes")

The following discussion from !5333 should be addressed:

- [ ] @paulobarros started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5333#note_1084189875):  (+2 comments)

    > @ebaque Hi Etienne, this looks good to me but I see that some jobs were not included in this categorization (e.g. the ones under the `zuora` folder and a couple more audit-related). Sorry for my lack of context but just for my understanding, could you elaborate a bit on that? I wonder why can't we apply the `:not_owned` category to those. Thanks!

Story points: 1.0
Update Subscription Stories in Storybook

The [subscription.stories.js](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/dcbaa3cf09dc0acfe3f32b73720077bebee98a02/stories/subscription.stories.js) is out of sync with the `subscription.vue` component.

For example the story of [Subscription - one product](http://localhost:6006/?path=/story/subscription--no-products) is displaying a renew button where there's no product available.

We should update the story accordingly and also update its format to use [controls](https://storybook.js.org/docs/react/essentials/controls).

Story points: 1.0