giseldo/neodataset huggingface dataset:
Add data mapping for Arrowsphere

### Background:

Previously Arrow system talks to Gitlab Platypus API endpoint(and then Platypus talks to CustomersDot). We will remove Platypus in this communication chain.

* previously(as of today): `Arrow -> Platypus -> CustomersDot`
* after removing Platypus, Arrow will directly talk to CustomersDot: `Arrow -> CustomersDot`

In order to achieve this, there are several changes required on CustomersDot side.

1. implement OAuth provider in CustomersDot. This allows secure API access control. We propose to use `doorkeeper` gem.
1. add required data mapping in CustomersDot. This maps some Arrow payload data to the CustomersDot/Zuora/SFDC required values.
1. track the Arrow order status. The status is used to:  allow Arrow to poll the order status; validate duplicate requests; ensure to take action safely only on the right order status.
1. provide API endpoint for Arrow to poll the order status.

For more information, refer to the task breakdown at https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4637#note_1062429151.

### This issue's scope

This issue covers the second task `add required data mapping in CustomersDot`

#### Proposal
Below are required mappings. Refer to [Arrow to Platypus mapping column](https://docs.google.com/spreadsheets/d/138UqGiYfGc8A4HyBin6JrsRelmjfGbqvg3UZ0nJaLTU/edit#gid=0&range=B1) to find the information on how to map these values.
   * externalSubscriptionSource: generated based on authenticated client(ATM the value is `Arrowsphere`)
      - Once doorkeeper authentication succeeds, we could get from `doorkeeper_token.application.name`. (when creating the OAuth application, set the application name as `Arrowsphere`)
   * fulfillmentDistributor: add a section in `application.yml`
   * $\['orderLines'\]\[0\]\['productId'\]: add a section in `application.yml`
   * $\['invoiceOwnerId'\]: add a section in `application.yml`
   * invoiceOwnerAccountNumber: add a section in `application.yml`


### 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: 2.0
Rename AmendmentManagerService service class

The following discussion from !5248 should be addressed:

- [x] @jagood started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5248#note_1079726703):  (+4 comments)

    > **thought**: I wondered at some point if it might make sense for this to be in the `Amendment` module? :thinking: 
    > 
    > ```ruby
    > module Zuora
    >   module Orders
    >     module Amendment
    >       module ManagerService
    > ```
    > 
    > Though I kind of like the combined `AmendmentManagerService` name better, I wonder if this might put it closer to other relevant code?  If it doesn't, then I wonder if that's a sign that there may be a better name for the class?

Story points: 1.0
Use named subject in upcoming renewal issues notifications spec

<!-- 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 per this [comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5307#note_1078434673), using a named subject could shorten the ~~`spec/services/auto_renew/send_upcoming_renewal_issues_notification_service_spec.rb`~~ `spec/services/auto_renew/send_ineligible_for_upcoming_renewal_notification_service_spec.rb` (file was [renamed](https://gitlab.com/gitlab-org/customers-gitlab-com/-/commit/2ecf43e7fd462b18d962345e8946f34e562a736a)) spec a lot. 
### Proposal
Use named subject in ~~`spec/services/auto_renew/send_upcoming_renewal_issues_notification_service_spec.rb`~~ `/spec/services/auto_renew/send_ineligible_for_upcoming_renewal_notification_service_spec.rb` (file was [renamed](https://gitlab.com/gitlab-org/customers-gitlab-com/-/commit/2ecf43e7fd462b18d962345e8946f34e562a736a)) as per this [comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5307#note_1078434673).

<!-- 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
Determine RenewSubscription order action using ActionTypeGenerator

<!-- 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

Use `ActionTypeGenerator` to determine when a request pertains to Renewing a subscription.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

![Amendment_Manager_Service_](/uploads/6be717aa794e29a447a0f206b7b30a30/Amendment_Manager_Service_.png)

In this issue, we address (1), (2) and (3) for 'RenewSubscription' functionality in the following ways:

(1) Add method `#check_renew_subscription` to `Orders::Amendment::ActionTypesGenerator`. The method returns based on the `params` whether a subscription is bring renewed. Use existing logic from `AmendSubscriptionService`.

(2) Add method `#renew_subscription` to `Zuora::Orders::FeatureAvailability`. This checks if `Unleash.enabled?(:use_orders_api_renew_subscription_workflow)` is enabled. Add `renew_subscription` to `SUPPORTED_TYPES` constant

(3) Create validator `Zuora::Orders::Amendment::Validators::RenewSubscription`. Implement `#validate` method that validates if the request for renewing a subscription is valid. Use existing validation logic from `AmendSubscriptionService`. If no validation is present, the validator can return an empty array.

Create FF `use_orders_api_renew_subscription_workflow`.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Determine AddProduct order action using ActionTypeGenerator

<!-- 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

Use `ActionTypeGenerator` to determine when a request pertains to Adding a Product to a subscription. 

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

![Amendment_Manager_Service_](/uploads/b37359b264167456112ca6f424f754b6/Amendment_Manager_Service_.png)

In this issue, we address (1), (2) and (3) for 'AddProduct' functionality in the following ways:

(1) Add method `#check_add_product` to `Orders::Amendment::ActionTypesGenerator` (see [`#check_renewal`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/25b8a23273d49cd86daeb538700f254c9e09fb75/app/services/zuora/orders/amendment/action_types_generator.rb) 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 `#add_product` to `Zuora::Orders::FeatureAvailability`. This checks if `Unleash.enabled?(:use_orders_api_add_product_workflow)` is enabled. Add `add_product` to `SUPPORTED_TYPES` constant

(3) Create validator `Zuora::Orders::Amendment::Validators::AddProduct`. Implement `#validate` method that validates if the request for adding a product is valid. (see [`Renewal validator`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/25b8a23273d49cd86daeb538700f254c9e09fb75/app/services/zuora/orders/amendment/validators/renew_subscription.rb) 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_add_product_workflow`.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Determine RemoveProduct order action using ActionTypeGenerator

<!-- 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

Use `ActionTypeGenerator` to determine when a request pertains to Adding a Product to a subscription.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

![Amendment_Manager_Service_](/uploads/dbc61937a3457100bb57862c7da552b0/Amendment_Manager_Service_.png)

In this issue, we address (1), (2) and (3) for 'RemoveProduct' functionality in the following ways:

(1) Add method `#check_remove_product` to `Orders::Amendment::ActionTypesGenerator` (see `#check_renewal` for implementation structure). The method returns based on the `params` whether a product is being removed from subscription. Use existing logic from `AmendSubscriptionService`.

(2) Add method `#remove_product` to `Zuora::Orders::FeatureAvailability`. This checks if `Unleash.enabled?(:use_orders_api_remove_product_workflow)` is enabled. Add `remove_product` to `SUPPORTED_TYPES` constant

(3) Create validator `Zuora::Orders::Amendment::Validators::RemoveProduct`. Implement `#validate` method that validates if the request for removing a product 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_remove_product_workflow`.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Determine UpdateProduct order action using ActionTypeGenerator

<!-- 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

Use `ActionTypeGenerator` to determine when a request pertains to Updating a Product in a subscription.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

![Amendment_Manager_Service_](/uploads/a92d9425d76d40b0b5312ccd2c52b37d/Amendment_Manager_Service_.png)

In this issue, we address (1), (2) and (3) for 'UpdateProduct' functionality in the following ways:

(1) Add method `#check_update_product` to `Orders::Amendment::ActionTypesGenerator` (see `#check_renewal` for implementation structure). The method returns based on the `params` whether a product is being updated. Use existing logic from `AmendSubscriptionService`.

(2) Add method `#update_product` to `Zuora::Orders::FeatureAvailability`. This checks if `Unleash.enabled?(:use_orders_api_update_product_workflow)` is enabled. Add `update_product` to `SUPPORTED_TYPES` constant

(3) Create validator `Zuora::Orders::Amendment::Validators::UpdateProduct`. Implement `#validate` method that validates if the request for updating a product 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_update_product_workflow`.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Integrate Remove product order action with OrderManagerService

### Problem

https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4721 implemented Order action `Zuora::Orders::Actions:: RemoveProduct` that constructs the request body to remove a product from a subscription.

The next step is to integrate this order action in `OrderManagerService`.

### Proposal

- Add ParamConstructor that constructs the payload required to remove a product.

Currently, removing a product is applicable:

1. when [upgrading / downgrading subscription's main product](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d2d6b0627183cb23baa6b296d76c3718ae7b56b5/app/services/amend_subscription_service.rb#L30)
1. when [migrating to ee v2 plan](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d2d6b0627183cb23baa6b296d76c3718ae7b56b5/app/services/amend_subscription_service.rb#L81)

Please note upgrade validation will be added as part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4753 and setting default payment before upgrade will be handled as part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4764.

### Result

Upgrading a subscription, requires both Adding a Product and Removing a Product functionalities.

Consequently, the upgrade workflow will not be e2e complete with this issue. However, we can use it to test a product is getting removed from a subscription.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Integrate AddProduct order action with OrderManagerService

### Problem

https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4722 implements Order action `Zuora::Orders::Actions:: AddProduct` that constructs the request body to remove a product from a subscription.

The next step is to integrate this order action in `OrderManagerService`.

### Proposal

* Add ParamConstructor that constructs the payload required to remove a product.

Currently, add a product is applicable when:

1. when [upgrading / downgrading subscription's main product](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d2d6b0627183cb23baa6b296d76c3718ae7b56b5/app/services/amend_subscription_service.rb#L30)
1. when [migrating to ee v2 plan](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d2d6b0627183cb23baa6b296d76c3718ae7b56b5/app/services/amend_subscription_service.rb#L81)
1. when [adding a new product / addon](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d2d6b0627183cb23baa6b296d76c3718ae7b56b5/app/services/amend_subscription_service.rb#L142)
1. when [adding a trueup](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d2d6b0627183cb23baa6b296d76c3718ae7b56b5/app/services/amend_subscription_service.rb#L162)
1. when [adding option products](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d2d6b0627183cb23baa6b296d76c3718ae7b56b5/app/services/amend_subscription_service.rb#L116)
Please note upgrade validation will be added as part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4753 and setting default payment before upgrade will be handled as part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4764.

Please note upgrade validation will be added as part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4753 and setting default payment before upgrade will be handled as part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4764.

### Result

This completion of this issue will enable performing e2e test of Upgrade workflow (requires `RemoveProduct` and `AddProduct`)

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Update default payment when customer is already associated with a Zuora account

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label in relevant trackers:

- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug
- https://gitlab.com/gitlab-org/customers-gitlab-com/issues?label_name%5B%5D=bug

and verify the issue you're about to submit isn't a duplicate.

Do not include confidential information!
--->

# Bug

For customers already associated with a Zuora account, the default payment ID needs to be set before creating a subscription.

If not, the subscription creation will result in the error: `To collect payment, the customer account must have a default payment method.`

`SubscribeService` [updated default payment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/9d9d6d56f56d596e0f98c52009e2a3638575f1c7/app/services/subscribe_service.rb#L20) before making a [subscription request](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/9d9d6d56f56d596e0f98c52009e2a3638575f1c7/app/services/subscribe_service.rb#L22) if the customer already has a Zuora account associated. This likely got missed when migrating to Orders API.

In addition, `CreationFollowupService` also needs to update the default payment ID (as done [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/9d9d6d56f56d596e0f98c52009e2a3638575f1c7/app/services/subscribe_service.rb#L195) in SubscribeService).

As part of the fix also update `OrderManagerService` spec to use `:with_zuora_account` trait (see [comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5290#note_1078327840)).

## Summary

(Summarize the bug encountered concisely)

## Steps to reproduce

(How one can reproduce the issue - this is very important)

## What is the current *bug* behavior?

(What actually happens)

## What is the expected *correct* behavior?

(What you should see instead)

## Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's tough to read otherwise.)

## Workarounds

(Ways to get around the issue)

## Reported examples

1.
1.
1.

<!---
Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 2.0
Order action for TermsAndConditions

<!-- 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 other Order actions implemented to renew a subscription, add, update and remove a product, we need an Order action to update [Terms and conditions](https://knowledgecenter.zuora.com/Billing/Subscriptions/Orders/AC_Orders_Tutorials/C_Change_the_Terms_and_Conditions_of_a_Subscription?_gl=1%2A1l4o63o%2A_ga%2AMzk3MTU1OTE4LjE2NDgwNjkzODE.%2A_ga_MY8CQ650DH%2AMTY2MTI2MzQ2My4yMTYuMS4xNjYxMjYzNTgzLjAuMC4w&_ga=2.3888562.30517363.1661062519-397155918.1648069381) of a subscription.

In the current workflow, terms and conditions of a subscription are updated when a subscription is auto-renewed ([source](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/3c782065f5922a8b54c1ebec1449d4f1f0edabe8/app/services/amend_subscription_service.rb#L141)).

### Proposal

In the module `app/services/zuora/orders/actions`, create a service class `UpdateTermsAndConditions`.

The service implements the following:

* inherits `Zuora::Orders::Actions::BaseService`
* defines `.execute` method that accepts `params` and instantiates an object of the class and invoked `#execute`
* defines `#execute` method

The `#execute` method constructs `orderAction` object to update terms and conditions of a subscription, with the below parameters:

| Parameter | Type | Description |
|-----------|------|-------------|
| `type` | String | Constant value: `TermsAndConditions` |
| `triggerDates` | Array of Objects | Each object has the keys: `name` and `triggerDate`. Defines `ContractEffective`, `ServiceActivation` and `CustomerAcceptance` dates as appropriate (see what dates existing workflow implements)|
| `auto_renew` | Boolean | Based on user input (included in `params`) |

Params are set in accordance to the current logic for updating terms and conditions in `AmendSubscriptionService`, please verify if any other param is set in existing implementation.

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

The service constructs the `orderActions` object to update terms and conditions of a subscription.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Preview amendment using Order's API

<!-- 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 amendment preview (before the actual purchase), we need a way to use the Orders API to preview an amendment.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Use Order Preview functionality introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4476.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Feature flag use of Orders API when updating 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

https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5254 introduced AmendmentManagerService that serves as an entry point to perform amendment operation using Order's API.

In order to use this service for Amendment operations, this issue pertains with using it in `SelfService::Subscriptions::UpdateService`.


### 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