giseldo/neodataset huggingface dataset:
Transitioning from Amendment.Name in Auto renewal

<!-- 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

This issue pertains to setting `order.description` to `AutoRenew by CustomersDot` during Auto renewal when using Orders API (instead of `name`). This is required as we transition from Amend to Orders API.

See more details on the motivation behind this change in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3784.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Params for auto renewal is generated by `AutoRenew::AmendmentParamsGenerator` service. Update `#run` method to set `order_description` when the FF `use_orders_api_auto_renew_workflow` is enabled. Default to `name` when FF is disabled.

### Result

With the implementation in this issue, the description will be set when Orders API is used for auto renewal.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Update CDot's BaseTrialService to route trials to Workato

<!-- 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

We're removing Platypus from the Trial Lead workflow so that work will need to be done via other methods. Currently Customers Dot's `BaseTrialService` [posts the lead to Platypus after the lead is created](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/ceda41a8af626cecb659b2230b9e445646bb78ae/app/services/gitlab/base_trial_service.rb#L20).

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

There are two places to change:
 - In place of the `BaseTrialService`'s existing `create_platypus_lead` create a new `create_workato_lead` method utilizing the Sidekiq worker from gitlab-org/customers-gitlab-com#5012. This new method will want to take the same information as the existing method but hand it off to a local Sidekiq queue instead of Platypus.
 - In `TrialsController`, create a new method `create_hand_raise_workato_lead` to replace existing `create_hand_raise_platypus_lead`.
 - Introduce a new feature flag `switch_lead_creation_from_platypus_to_workato`

### Result

We're able to complete the full trial lead process without involving Platypus in the process.

### Next steps (if any)

Roll out the new method of posting Leads via a feature flag.

### How will we measure success?

We will consult with the Marketing Operations team to ensure that the newly posted data in Workato conforms to expectations and will work as expected for them in downstream processes.

Story points: 2.0
Create a sidekiq worker to send trials to Workato

<!-- 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

We're working to remove Platypus from the trial creation pipeline, but want to retain Workato as part of the process. Currently Platypus handles trial lead storage via an [asynchronous Bull worker](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/integrations/platypus/-/blob/master/apps/server/src/marketing/commands/new-lead.command.ts#L42) that disconnects the time needed to service the request from the customer facing HTTP flow, the worker also handles posting failures to slack and email as needed.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Create a Sidekiq worker to do the same tasks currently being done by the Bull worker within Playtups.

### Result

Customers Dot can now post new leads to Workato with the same level of error reporting currently available in Platypus.

### How will we measure success?

Leads can be successfully posted from Customers Dot.

Story points: 1.0
Create Workato service within CDot

<!-- 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

Customers Dot is not currently able to communicate with Workato to post leads from trials.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Workato uses OAuth and a REST api, customers dot already includes gems for handling both of those methods of communication. We just need to take the pieces and assemble them into a service that will allow us to post leads to Workato in a practical convenient way. To do this we will create a service that will abstract secret handling and routing requests to the correct end point on Workato.

The only method that we need to implement at present is POSTing to `https://apim.workato.com/marketo/lead`. There isn't solid documentation on fields available with that end point, however the [existing Platypus Service](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/integrations/platypus/-/blob/master/apps/server/src/marketing/commands/new-lead.command.ts#L12) includes the names and types of all of the elements that we would want to include in our request.

We also need to create a new `Workato::LogLeadService` to replace existing `Platypus::LogLeadService`

### Result

There is a convenient service available to help facilitate the implementation of other tickets under this epic.

### How will we measure success?

Work on gitlab-org/customers-gitlab-com#5013 is able to proceed.

Story points: 3.0
[Reseller] Update details in email sent out on purchasing/renewing SaaS subscription

<!-- 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
Currently the email which is sent out to customers on purchasing subscriptions via reseller flow mentions that they would not have access to the CustomersDot account. With https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5002, we would be allowing such customers to login to CustomersDot account.
We should update the email body to change this communication. 

Current email sent - 
![image](/uploads/168258b33f10ee08fbd1baa92627a1e2/image.png)

### Proposal

Update email body to remove the part which mentions that customer will not have access to the CustomersDot portal.  This should be behind the feature flag created in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5007.

### Proposed email text

_Anchor links remain the same as current implementation._

---

**Subject: [GitLab Transactions] Set up your new subscription to get started**

---

Hi Sharmad :wave: 

Thanks for purchasing a GitLab.com subscription. To set up your new subscription, you must link it to a group. Complete the following steps:

1. Create your GitLab account.
   - If you're already registered, [sign in](link).
1. Select the group for your subscription.
   - Create a new group or for an existing group, make sure you have the [Owner](link) role.
1. Sign in to your Customers Portal account. 
   - If this is your first purchase, we've sent you an email with instructions to set your password and access your account.
1. Link your GitLab account and subscription.
   - [Link your GitLab user account to your Customers Portal account](link).
   - [Link the subscription to your namespace](link).
1. [View your GitLab SaaS subscription](link) to confirm it's linked to a group.

If you require assistance, contact GitLab support.

Thanks,

The GitLab Team

---

### Result

Reseller customer receives correct information about getting access to Customers Portal and provisioning their SaaS subscription.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
[SPIKE]: Investigate "PaymentFormsController#show" speed

From: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4918#note_1142253500

### Problem
`PaymentFormsController#show` fails to meet it's apdex requirements 70% of the time.

### Context
`PaymentFormsController#show` is currently set at `:default` urgency. This means it will fail apdex if requests take longer than 1 second. [Reference](https://docs.gitlab.com/ee/development/application_slis/rails_request_apdex.html#how-to-adjust-the-urgency)

On average, these requests are taking longer than 1 second 70% of the time:
![Screen_Shot_2022-10-19_at_3.13.25_PM](/uploads/2d8e92b5853f55d15de641c8fbf4d5d0/Screen_Shot_2022-10-19_at_3.13.25_PM.png)

### Results
1. Find way to optimize endpoint so requests take less than 1 second.
2. If not possible, decrease the urgency so we allow up to 5s.

Story points: 2.0
Enable use of Orders API in Reconciliation 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

`ReconciliationService` currently uses [Amend API](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/1c7002a2ef484ff3db77db80be29a08785e1b339/app/services/reconciliation_service.rb#L101) to perform reconciliation. Update it to use Orders API instead.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Update `ReconciliationService#amend_subscription` to invoke `Zuora::Orders::AmendmentManagerService` with appropriate params when the FF `use_orders_api_reconciliation_workflow` is enabled.

### Result

Reconciliation is performed appropriately when Orders API is used.

Verify: `contract_effective_date`, updated `quantity`.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Rename Account model to BillingAccount

### Background

In today's [sync meeting](https://docs.google.com/document/d/1_YbxNCo3KXK1-KdIZTgSvmU9kIslYjQnFZAmmu1DSqQ/edit#heading=h.lif00r71v2kb), it was suggested that the `Account` model name could be improved by renaming to `BillingAccount`.  This should avoid confusion in thinking an `Account` in CustomersDot is the same as a GitLab `Organization`.

We also want to standardize naming across our Order to Cash systems in https://gitlab.com/groups/gitlab-org/-/epics/9018.  Given this, we've identified the column name `BillingAccount.name` should be `BillingAccount.zuora_account_name` to avoid confusion.

### Proposal

Rename the `Account` model to `BillingAccount` avoid confusion.  Given we are renaming `Account`, let's also rename `AccountMembership` as well.

- Rename model `Account` to `BillingAccount`
   - Rename DB table `accounts` to `billing_accounts`
- Rename model `AccountMembership` to `BillingAccountMembership`
   - Rename DB table `account_memberships` to `billing_account_memberships`

Also rename the column `BillingAccount.name` to `BillingAccount.zuora_account_name`.

Story points: 2.0
Investigate: `invoice.DMRC` mismatch during Renewal+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

During Renewal + Upgrade, `DMRC` for the invoice's rate plan charge when triggered by Amendment vs Orders API is different.

|  | Amendment API | Orders API |
|--|---------------|------------|
| Subscription link | [Link](https://apisandbox.zuora.com/platform/subscriptions/8ad0877b83babdd00183ce8be0050f0d) | [Link](https://apisandbox.zuora.com/platform/subscriptions/8ad09c4b83bacd5d0183ce8563260443) |
| Invoice Item ID | `8ad0877b83babdd00183ce8be0f40f29` | `8ad09c4b83bacd5d0183ce8565010532` |
| Rate Plan Charge ID | `8ad0877b83babdd00183ce8be0440f1d` | `8ad09c4b83bacd5d0183ce8563af046f` |
| DMRC | **0** | **1188** |

**Steps to reproduce**:

* Purchase a Premium Subscription
* Login to CDot
* In the subscription card, select 'Renew'
* Select Ultimate plan, enter quantity and submit

**Additional references**:

* See tab two (`Renewal + Upgrade`) in [spreadsheet](https://docs.google.com/spreadsheets/d/1mydR5iZd4709tLkKRal30vE3Xad1dsxGOzCwhiwB7HQ/edit#gid=179256484) for full comparison

### 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: 2.0
Account details form updates BillingAccount model

### Problem

The current Account details form in CustomersDot updates the `Customer` (to be renamed `User`) record which has ActiveRecord callbacks to update the Zuora Account and Zuora Contact.  The Zuora Contact updated by this callback is [simply the first Zuora Contact associated to the Zuora Account](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/58c2d92e7fb4892f2326423300e6b9f6267a9632/app/services/update_contact_service.rb#L26).  It is a known bug that if the Zuora Account has more than one Zuora Contact, there is no guarantee this logic updates the correct Zuora Contact.

For reference, here's what the page looks like currently:
![Screen_Shot_2022-09-12_at_6.02.09_PM](/uploads/34922ad336fcff352258ac3c31cda96c/Screen_Shot_2022-09-12_at_6.02.09_PM.png)

Now that `BillingAccount` information is being stored locally, this form should also update `BillingAccount` locally as well as in Zuora.

### Proposal

The Account details form should allow the following:
- Show and update (local) `BillingAccount` record
- Show and update (remote) Zuora Account
- Show and update (remote) Zuora Contact (the correct one)

The look of the form should not need to change in this iteration as the app still only allows one `BillingAccount` per `Customer` (to be renamed `User`).  This form will be updated in later iterations as well, both in https://gitlab.com/groups/gitlab-org/-/epics/8951+ and https://gitlab.com/groups/gitlab-org/-/epics/8986+.

Story points: 3.0
Customers with different BillTo/SoldTo contacts on the Zuora account are not receiving a Welcome email

### Problem

As identified in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4924+, customers that are purchasing directly from GitLab via a Sales Rep are not receiving the Customers Portal [welcome email](https://gitlab.com/gitlab-org/customers-gitlab-com/uploads/92e7ac101afa342c73a8896285e83ef6/welcome-to-portal-email.png). This only happens if the Sales Order (and Zuora account) has different contacts for BillTo and SoldTo.

### Proposal

Per [suggestion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4924#note_1126792349) from `@tyleramos`:

>>>
I think if we agree that this logic is flawed, and the purpose of billable was to determine reseller subscriptions, we should probably just remove the `billable` column altogether. We already have an accurate way of calculating [subscriptions managed by resellers](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/01600a67144b2b47ba1857794f02ebb897a2e27b/lib/zuora/subscription.rb#L74) which is [used to determine the ](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/6d78d7ab5044fdb102e85f4f4709251f7384d99f/app/workers/zuora_callout/base_worker.rb#L25)`login_activated` boolean column when processing callouts.

We should be able to simply remove the logic and column for `billable` and the welcome email would be sent to new customers that have zuora accounts and their subscription wasn't managed by a reseller. That seems like the desired behavior. We would have no need to send the `bill_to_id` at that point too, so it would be some simplification of the code and the params in the configured callouts.
>>>

* Reference to code that triggers the welcome email: https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/a370c2b4b1a4fec50a6be2291c7b0ec7c73e0cd7/app/services/find_or_create_customer_service.rb#L79
* Reference to code where `billable` is set: https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/a370c2b4b1a4fec50a6be2291c7b0ec7c73e0cd7/app/services/find_or_create_customer_service.rb#L62

### Result

All customers that purchase directly from GitLab (not Reseller) will receive a [Welcome email](https://gitlab.com/gitlab-org/customers-gitlab-com/uploads/92e7ac101afa342c73a8896285e83ef6/welcome-to-portal-email.png).

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Create proposal doc with ERD

### Background

We would like to create a proposal document that lives in the customers-gitlab-com project.  This is a great way to spread awareness and create an SSoT for the overall scope of work involved in the epic.  This was identified as a goal in our weekly sync meeting agenda [here](https://docs.google.com/document/d/1_YbxNCo3KXK1-KdIZTgSvmU9kIslYjQnFZAmmu1DSqQ/edit?disco=AAAAhbdDiNI).

Story points: 1.0
Add proration custom attributes in subscription update response

<!-- 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

Similar to the addition in Order preview, the [proration custom attributes](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/ac19a2843ad59a38351558c4e77b2e4b90fd7ee7/app/services/amendment_base_service.rb#L82) needs to be included in the Order response when updating subscription.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Include proration custom attributes in [`Zuora::Orders::AmendmentManagerService#success`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/f38128d5dd47c74f02635ea12b823bb27799c3d8/app/services/zuora/orders/amendment_manager_service.rb#L71).

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Enable use of Orders API in Auto renewal 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 auto renewing subscription in ReconciliationService and in Reconciliation workflow, FF use of Orders API.

### 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: 2.0
[Reseller] Display a banner with info on how to modify a reseller-purchased subscription

<!-- 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

Customers that purchased their subscription through a reseller will be able to see but not modify that subscription (issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4946+)

It would be confusing to them why they aren't able to do anything to the subscription.

## Proposal

Display an alert at the top of the manage purchases page with a message to contact their reseller.

### Alert copy

>>>
**Some or all of your subscriptions are in read-only mode**

To make changes to a read-only subscription or purchase additional products, contact your GitLab Partner.
>>>

- [x] `@cfarris` reviewed and approved
- [x] `@esybrant` reviewed and approved  
- [x] `@fneill` reviewed and approved  

## Result

## Next steps (if any)

## How will we measure success?

Story points: 2.0