giseldo/neodataset huggingface dataset:
Backfill tasks should reference zuora_account_id column instead of overwritten method

### Problem

As described in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4867#note_1247871087, we found after enabling the `account_data_structure` feature flag that the backfill rake task `lib/tasks/data_maintenance/billing_accounts/backfill_with_customers.rake` no longer works.  This is because the rake task uses `customer.zuora_account_id` which is an overwritten [attr reader method on Customer](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/aa5aec8253fdad5cb4b846a6d778739fd37affcc/app/models/customer.rb#L162).  When the flag is enabled, this method pulls the `zuora_account_id` from the `BillingAccountMembership` instead of directly from the Customer column.

### Proposal

Update the rake task to use the `zuora_account_id` directly on the Customer record (e.g. `customer[:zuora_account_id]`) instead of the reader method on Customer.

### Result

The rake task continues to work even after the feature flag is enabled.

Story points: 1.0
New account purchase creates separate Bill and Sold To Contacts

### Problem

We noticed while troubleshooting https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5449+ that when purchasing a subscription with a new Customer (e.g. no associated Zuora Account), the Order API actually creates separate Bill To and Sold To Contacts that have identical information.  I believe this is a change in behavior from the existing Subscribe API.

This is an example of a Zuora Account created while making a new account purchase in my local CDot: https://apisandbox.zuora.com/apps/CustomerAccount.do?method=view&id=8ad08d2985c4e1580185c5a8bebf51a9.  Notice this the separate contact records that have the same information.

### Proposal

I've found that the Orders API requires [an additional parameter](https://www.zuora.com/developer/api-references/api/operation/POST_Order/#!path=newAccount/soldToSameAsBillTo&t=request), `soldToSameAsBillTo`, to instruct Zuora to create the Account with the same Contact record for Bill to and Sold to.  I've already tested this by adding this param and [the resulting account](https://apisandbox.zuora.com/apps/CustomerAccount.do?method=view&id=8ad0889d85c4e1560185c5afc1b52cbe) was created with the same Contact for both Bill to and Sold to as expected.

Story points: 1.0
Skip license notification for non-ramp subscriptions if no new license is required

### Problem

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5242+, notifications are skipped if nothing has changed in the new ramp interval. For Multi-Year subscriptions that are non-ramp, the same should apply as discussed [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5242#note_1244526220).

### Proposal

Remove the check for the subscription to be ramp enabled ([code](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e5a66632e43ba7595e62b644c376b3d5f70ebdcf/app/services/license_notification_service.rb#L92)) as well as [this code comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e5a66632e43ba7595e62b644c376b3d5f70ebdcf/app/services/license_notification_service.rb#L43) to also skip the notification for non-ramp subscriptions.

### Result

Same behaviour for all Multi-Year subscription regardless of being for a ramp or not by skipping the notification if nothing has changed has changed in the new year of the subscription and no new license is required.

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

Let's make sure that we write/exit specs to ensure that this works as expected.

- Validate skip license notification for non-ramp subscriptions if no new license is required
- Validate skip license notification for non-ramp subscriptions if a new license _is_ required
- Validate skip license notification for ramp-enabled subscriptions if no new license is required
- Validate skip license notification for ramp-enabled subscriptions if a new license _is_ required

Story points: 2.0
[Auto-Renew] Send a failure notification for multiple rate plans if Cloud License is disabled (SM).

### Problem
Linking [comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5335#note_1237671684), currently we are not sending any failure notifications to auto-renewable subscriptions having multiple rate plans ([context](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5355)) even if Cloud Licensing is disabled for such subscriptions.

### Proposal

If a self-managed auto-renewable subscription fails eligibility due to multiple rate plans, check if Cloud Licensing is disabled for this subscription and send them the failure email.

Email issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4421

Story points: 2.0
Allow admin resend of cloud activation code even if there is an activated instance present

### Problem

With the implementation of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4023+, we do not send out the activation code email again after an activated instance is present. This is useful for avoiding to send out the activation code again in case of a renewal or other amendments to the subscription. However, this may have a side effect as this logic also prevents to resend the activation code in the Admin. This wasn't needed so far but after reconsideration it might make sense to provide this ability in the Admin.

### Proposal

Allowing for resendof an activation code in the Admin even if there is an activated instance present for the subscription.

### Result

Ability to resend activation code in the Admin no matter the current state of activation.

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

**Considerations:** 
- Is there any prevention mechanism to resend this code?
- Will the resending of the activation code result in an accidental re-activation? (i.e., will it generate a new activation code?)

1. View / Vue spec to validate presence of "Resend Activation Code" button
1. View /Vue spec to validate absence of button when license is not "cloud license"
2. Feature specs
    * If button is clicked, validate the proper mailer has been invoked
    * Button should be visible for activated/non-activated instances

Story points: 2.0
Add Group Name link to subscription-v2 component



### Proposal
Add a link to the group name in the new SubscriptionV2 component. There will also be a popover when hovering on the group name.

### Result
Design: [GL issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3916/designs/Ramped_subscriptions__MVC.png) and [Figma](https://www.figma.com/file/U9JvYVy1Ls9IKrrPw1vt38/Update-subscription-card-to-reflect-Zuora-data-structure?node-id=239%3A13266&t=jdt2nnkIH74aLlA3-0)

Story points: 3.0
Follow-up from "Determine PRP for renewal from subscription object"

The following discussion from !6176 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6176#note_1235822858):  (+1 comment)

    > **Suggestion (non-blocking/follow-up):** If we define `with_one :rate_plan_charge` in [`lib/zuora/invoice_item.rb`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/35aa538b8992a7ae8519dc513f6beda6e271c32e/lib/zuora/invoice_item.rb), I think it would simplify this a bit and we could call `invoice_item.rate_plan_charge` instead.  It looks like this happens in a few other places in this file too.
    > 
    > Not a blocker for this MR IMO since it was this way before, but might be a nice quick follow-up if you like.

Story points: 1.0
Develop Retention Policy for Container Registry

<!-- 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

Now that the Container Registry is enabled, and given that https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6229+ will implement Continuous Deployment to the registry ...

These containers will take up a lot of space and some containers will never be used.

### Proposal

Develop a retention policy for the Container Registry, to preserve money and space.

### Result

Old published images pushed to the container registry will be purged.

### Next steps (if any)

Depends on https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6229+ to be merged.

### How will we measure success?

Story points: 1.0
Use `provide` to pass subscription to Activation components

<!-- 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
### Proposal

To more easily maintain a [second code path](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5382) for generating the `Activation` components, convert to using `provide` instead of prop-drilling fields.
<!-- 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
[Ramps] Add method on RatePlanCharge to reject duplicate segments

<!-- 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 mentioned in this [comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6233#note_1232817247), we can move the filtering logic for `rate_plan_charges` to `Zuora::RatePlanCharge` from `subscription_presenter.rb`.

### 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
Get zuora_account from Order in AutoRenew::BasePresenter

### Problem

In `AutoRenew::BasePresenter`, the `zuora_account` is used to [get the default payment method](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/b5e4974cf7a33400945369b06d199fa842cc1261/app/presenters/auto_renew/base_presenter.rb#L31).  This is fetched from the given `customer` (e.g. `customer.zuora_account`).  However, it would be more accurate long-term when the `account_data_structure` is in place to pull this from the `order` instead.

### Proposal

Update `AutoRenew::BasePresenter` to get `zuora_account` from the `order` when the `account_data_structure` feature flag is enabled.

Story points: 2.0
Update namespace for Zuora and SFDC cleanup tasks

### Summary

We have a couple of tasks to cleanup Zuora and Salesforce related references:
- `clear_missing_zuora_account_ids` task
- `clear_missing_salesforce_account_ids` task

These are namespaced under `:customers`.

With the work related to billing accounts these cleanup tasks will be handling the update of the customers and the billing accounts and eventually just the billing accounts.

### Proposal

Update the namespace to `:data_maintenance` for:
- `clear_missing_zuora_account_ids` task
- `clear_missing_salesforce_account_ids` task
- the documentation referencing any of this

Story points: 1.0
Review and add missing docs for "AutoRenew" feature

### Section 3: GitLab initiated management events

This issue is to create a SSOT for all documentation about "AutoRenew" feature. Follow the checklist below:

#### Feature: AutoRenew

Review existing documentation and update this issue with:

- [ ] User facing docs: links
- [ ] Developers docs: links
- [ ] (Optional) Flowcharts: links
- [ ] Add links from above to the Fulfillment Guide

Story points: 2.0
Review and add missing docs for "Renew subscription" feature

### Section 2: User initiated management events

This issue is to create a SSOT for all documentation about "Renew subscription" feature. Follow the checklist below:

#### Feature: Renew subscription

Review existing documentation and update this issue with:

- [x] User facing docs: links
- [x] Developers docs: links
- [x] (Optional) Flowcharts: links
- [x] Add links from above to the Fulfillment Guide

Draft MR: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/118919

Story points: 2.0
Pass long tail description as jtbd when create Workato lead

This [request](https://gitlab.com/groups/gitlab-org/-/epics/9084#note_1187675882) asks to change current `jtbd` value from `Reason API` to `long tail` value.

>>>

One more question from my side: is it possible to change the values on the jtbd fields sent over according to the table below:


| Reason API | long tail |
| ------ | ------ |
| basics | I want to learn the basics of Git |
| ci | I want to use GitLab CI with my existing repository |
| code_storage | I want to store my code |
| exploring | I want to explore GitLab to see if it's worth switching to |
| move_repository | I want to move my repository to GitLab from somewhere else |
| other | A different reason |

>>>

Also per [comment](https://gitlab.com/groups/gitlab-org/-/epics/9084#note_1195974830):

>>>
 * if the jtbd is in the defined values, map to the long tail according to the table
 * if the jtbd is NOT in the defined values, keep whatever the jtbd value, and pass to Workato as it is.

BTW: I searched production DB, here are the existing jtbd values count:

```
irb(main):006:0> pp  Lead.group(:jtbd).count
{""=>2543,
 "9v5lw024chiooua11lmr9utqmhsag1d51xpocf04.burpcollaborator.net"=>1,
 "basics"=>8878,
 "ci"=>4475,
 "code_storage"=>13702,
 "code_storageofeof%>r8hri'/\"<infpc"=>1,
 "exploring"=>7362,
 "move_repository"=>4210,
 "other"=>7367,
 nil=>142237}
```
>>>

#### Other consideration

It is better to introduce a feature flag to control this behaviour, to help this behaviour transit smoothly.

Story points: 1.0
Sync SoldTo to Zuora for email address updates from Admin

## Problem

When the email address of a customer gets updated from the admin interface it doesn't sync automatically with Zuora.

This is a problem, as the `SoldTo` contact in Zuora should get updated in this case as well.

<details><summary>Screenshot of CDot Admin</summary>
![Email_Update_Admin_CDot](/uploads/5cafcfa08542ed32b24cf4c9c7308e95/Email_Update_Admin_CDot.png)
</details>

Related thread: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5139#note_1220323298

## Proposal

Update the Zuora `SoldTo` contact when a customer email address is updated via the admin interface.

## Result

When the email address of a customer gets updated from the admin interface it gets automatically synced with Zuora `SoldTo` Contact.
This allows us to have the same behavior for Zuora `SoldTo` contact sync updates within CDot.

Story points: 2.0
Create documentation for how to augment the dictionary

After introducing the dictionary to map system to friendly errors, we need to document how to extend the dictionary so that not only Fullfilment engineers but stakeholders (e.g., Support engineers) can introduce new friendly errors.

This will be the first iteration of the documentation and process. One place where this can be put in is the [architecture](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/doc/architecture) section of CustomersDot documentation.

Story points: 1.0
Allow Workato::CreateLeadWorker to retry lead creation failure


We found several unsuccessful Workato lead creations. 
- First one: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5418#note_1222258595. The root cause is unstable network `Net::ReadTimeout` https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5418#note_1222259741
- Second one: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5418#note_1223316962
- Third one: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5418#note_1224676382
- Fourth one: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5418#note_1225168532

Although there are different reasons for the above 4 unsuccessful cases, they could all succeed with a retry.

ATM, if `Workato::CreateLeadService.new.execute(lead_attrs)` returns `success: false`, `Workato::CreateLeadWorker` does NOT do anything.

We should retry Workato::CreateLeadService failures. (BTW: `Workato::CreateLeadWorker` is safe to retry -- if the lead already exists, Workato will update existing lead.)

**BTW**: searching from the production Lead table, it shows that: [Platypus::CreateLeadService also had some unsuccessful instances](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5445#note_1222271404), but we did not remedy them.

Story points: 2.0
Document new process for managing Customer associations with Zuora Billing Accounts

### Problem

With the data structure changes introduced in https://gitlab.com/groups/gitlab-org/-/epics/8950+, team members outside of Fulfillment who routinely use CDot need to be aware of these changes.  In particular, CDot Admins who might manage Zuora Billing Account associations for Customers.

Previously, the Admin page for Customers allowed admins to change the `zuora_account_id` for a Customer as shown below.

![Screen_Shot_2022-12-21_at_11.43.56_AM](/uploads/d749e76bcf80a8079f75d347f3714b00/Screen_Shot_2022-12-21_at_11.43.56_AM.png)

When the new data structure goes live (`account_data_structure` feature flag enabled), this ability will change.  The `zuora_account_id` field on the Customers page will be removed.  Instead, the association to a Zuora Account will be managed through a Billing Account Memberships.  A Billing Account Membership can be created or removed which associates a Customer with a Billing Account record.  The following screenshot shows the new Billing Account Memberships page.

![Screen_Shot_2022-12-21_at_11.46.33_AM](/uploads/45f2b45a830253d8d885369e63a5898c/Screen_Shot_2022-12-21_at_11.46.33_AM.png)

The Billing Account is the record that has the association with a Zuora Account and has the `zuora_account_id` field as shown below.

![Screen_Shot_2022-12-21_at_11.48.56_AM](/uploads/a60922e01f2e5df89626c78f39478178/Screen_Shot_2022-12-21_at_11.48.56_AM.png)

### Proposal

Let's consider documenting this information and communicate this to team members in advance of rolling out the `account_data_structure` feature.

People include when communicating this documentation:
- Finance systems and Billing team (`@annapiaseczna` for instance)
- Support team

As noted by `@kevenhughes` [below](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5434#note_1234552915), [support workflows documented in the handbook](https://about.gitlab.com/handbook/support/license-and-renewals/workflows/) will likely need to be updated. For instance, the workflows [listed here](https://about.gitlab.com/handbook/support/license-and-renewals/workflows/customersdot/associating_purchases.html#add-subscription-management-contact-workflow).

Story points: 2.0
Add Marketplace order status poll endpoint to OpenAPI doc

In issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4733+, we have created endpoint for Marketplace partners to poll order status.

We need to add this new endpoint to the openAPI doc https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/doc/api/openapi.yaml

### Problem

### 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 product sub type attribute for subscriptions

<!-- 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
For ramp subscriptions, we need to show different products (plan, CI minutes, storage) in their own sections as per the [new design](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3916/). For this we need an identifier on each product as to what type of product it is.  
![image](/uploads/ea5af87826e42aaecbf911d30d707916/image.png)

### Proposal
On the product level we need to add another attribute `sub_type` which will have value `plan`, `storage`, `ci-minutes` based on the kind of product. This will be used on the frontend to show different product section on the new subscription card.  
Also add the `rate_plan_id` which will be used to map each product against the ramps which will be sent in a different key in this issue - https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5375.

<!-- 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: 2.0