giseldo/neodataset huggingface dataset:
Remove heading overrides

<!-- 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 we override headings (h1, h2) styles in https://gitlab.com/gitlab-org/customers-gitlab-com/blob/main/app/assets/stylesheets/main.scss#L8 We need to remove these, add proper spacing anywhere if required. 

### 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
Update CDot Storage purchase flow to behave like the one in gitlab.com

### Problem

It has been identified that CDot Storage purchase flow is [incompatible with the new Orders API](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4891#note_1141305264), due to some missing parameters in the Orders Preview API response to enable the user experience.

<details><summary>Click to see a screenshot</summary>
![CleanShot_2022-11-05_at_14.56.47_2x](/uploads/b7ee99e1b702c85c5c814846f27a6d3a/CleanShot_2022-11-05_at_14.56.47_2x.png)
</details>

CDot Storage purchase flow is being used by customers purchasing Storage for their personal namespaces and [customers with no last name](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4891#note_1150817989).

This issue is a blocker to completing https://gitlab.com/groups/gitlab-org/-/epics/8665+.

For additional discussions about this issue, please see https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4891.


### Proposal

1. Update CDot Storage purchase flow to look like and behave like gitlab.com Storage purchase flow (reference in Emily's [comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4891#note_1141770681))
1. CDot flow uses some variables that are not available once we transition to Orders API
1. We want CDot flow not to use those variables, and one way to do it is to align it to gitlab.com flow (which doesn't use `unit_price` variable)

<details><summary>Click to see a screenshot</summary>
![gitlabcom_storage_purchase](/uploads/e1b41c518e0a8f0cc247a8d943a7f68d/gitlabcom_storage_purchase.png)

</details>

Story points: 5.0
Old licenses unable to seat link due to missing zuora_subscription_name

### Problem

In 2021/03 [we started to add `zuora_subscription_name`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2985/diffs#e4b267ec5ccedfebb4a6917d5f020bb4a4162d1b_83_83) when generating licenses. 

However the current seat link requires `zuora_subscription_name` for the purpose of finding `Order`. Therefore old licenses would fail to seat link.

Example: https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/3443377/events/119391762/

~~This error counts towards our error budget.~~ Currently this cause 422 response and should not count as apdex failures.

### Proposal

Either of the following:

1. Old licenses still has `subscription_id`. We can use that to either find Order directly, or find the subscription name.
1. Or, we can make seat link skip these type of errors, so they won't count towards error budget. This may be preferable if we don't care about old license data too much, and they will be rarer as time goes by.

### Result

Old license can still seat link.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Whitespaces in contact email lead to validation error on customer creation

### Problem

While looking into failed `Provision` records (e.g. https://customers.gitlab.com/admin/provision/10708 or https://customers.gitlab.com/admin/provision/10853), it turned out that they were audited as failed because a `Customer` record could not be created. It could not be created due to the used email already existing in the system in a `Customer` record.

The used workflow for the `Customer` record creation uses [FindOrCreateCustomerService](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e9eaf1283947f750b763c9e179626f0bbb341284/app/services/find_or_create_customer_service.rb). This service first attempts to [find a `Customer` record](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e9eaf1283947f750b763c9e179626f0bbb341284/app/services/find_or_create_customer_service.rb#L14) via email before [creating a new one](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e9eaf1283947f750b763c9e179626f0bbb341284/app/services/find_or_create_customer_service.rb#L17) in case none was found. This doesn't add up with the error we are seeing though (since first no record was found but then on creation there suddenly was one). Looking closer into the used emails, it turns out that the two mentioned examples both have a `\t` (some kind of whitespaces) at the end of the email. While it's correct that no `Customer` record is found when looking for one by email, upon attempting to create one, I think devise will automatically strip the whitespace from the email ([code](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e9eaf1283947f750b763c9e179626f0bbb341284/config/initializers/devise.rb#L56)). Which explains why the email already exists error shows up at that step.

### Proposal

Strip any whitespaces before looking for a `Customer` record by email in the `FindOrCreateCustomerService` ([code](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e9eaf1283947f750b763c9e179626f0bbb341284/app/services/find_or_create_customer_service.rb#L45)).

### Result

Stripping the whitespace before the lookup will find the already existing `Customer` record and any workflow that is supposed to be executed along with this logic will succeed and not fail anymore.

Story points: 1.0
Follow-up from "Use orders api in order preview graphql resolver"

The following discussion from !5701 should be addressed:

- [x] @tvellishetty started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5701#note_1156798990):  (+2 comments)

    > That seems to be a fairly new change in AmendSubscriptionService, do you think we should consider doing the same in AmendmentManagerService instead of accepting a customer param?

# Proposal

use `subscription.sold_to_customer` in `AmendmentManagerService` instead of accepting a customer param to be consistent with `AmendSubscriptionService`

Story points: 2.0
Update Subject Line of SaaS Provisioning Email for more obvious CTA

<!-- 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 SaaS provisioning subject line does not make it obvious that action needs to be taken.

A change in subject line was first proposed in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5003, but this issue is expected to take a long time to deploy given it is blocked by https://gitlab.com/groups/gitlab-org/-/epics/8941.

### Proposal

Update the subject line of the SaaS Provisioning email from `[GitLab Transactions] Thanks for purchasing our GitLab.com hosted plan!` to `[GitLab Transactions] Set up your new subscription to get started`.

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result
Email contains a more obvious CTA, customers know they need to open the email.

### 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 -->

If we do not have one already, we should consider adding a Mailer spec to validate this subject text.

```ruby
expect(mailer.subject).to eq('[GitLab Transactions] Set up your new subscription to get started')
```

Story points: 1.0
[Reseller] Hide `Buy new subscription` button for customers who have purchased subscription through reseller

<!-- 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 customers who have purchased subscriptions through resellers, we should hide the "Buy new subscription" button.

![cdot-sm-subscription-card-crossed](/uploads/268a4f53a15dd0972e6512e9a0559ac0/cdot-sm-subscription-card-crossed.png)

Note: Subscription management buttons will be hidden for reseller subscriptions in this issue - https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4946. In the current issue we need to tackle hiding the `Buy new subscription` button.

### Proposal

1. If a customer has an active subscription that was purchased via a Reseller, they **should not be able** to buy a new subscription.
   * Add 30 days to the SubscriptionEndDate of `Active (reseller) subscription` to account for the renewal term
   * 30 days is based on https://about.gitlab.com/handbook/sales/field-operations/order-processing/#late-renewals
1. If a customer purchased via a reseller in the past, and no longer has an active (reseller) subscription, they **should be able** to buy a new subscription.

### Implementation
| MR | Description |
| ------ | ------ |
| https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5925       |  Add `managed_by_reseller` attribute to subscription presenter output       |
| https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5926       | Hide `Buy new subscription` button if any of the subscriptions have `managed_by_reseller` true      |

### Result

### Next steps (if any)

- [x] @tgolubeva: Respond to https://gitlab.com/gitlab-com/support/ticket-attention-requests/-/issues/3095#note_1166598959 once this issue is closed.

### How will we measure success?

Story points: 2.0
[Testing] Use of Orders API in Order Preview GraphQL endpoint

### Problem

This issue is to track the verification process to enable the use of [Use of Orders API in Order Preview GraphQL endpoint](https://gitlab.com/groups/gitlab-org/-/epics/9118).

**Associated FF:** [`use_orders_api_in_preview_graphql_resolver`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5068)

### Testing scenarios
| Scenario | Steps | Expected result | Pass? (Staging environment) | Notes |
|----------|-------|-----------------|-----------------------------|-------|
| Preview storage purchase in Gitlab  | 1. In Gitlab open an existing group with a paid plan or create a one. <br> 2. Navigate to Group > Settings > Usage Quotas > Storage tab <br> 3. Click on Purchase more storage | We should see the correct prorated "Total" in the UI | yes |  |

### Result

### Next steps (if any)

Story points: 1.0
[Testing] Auto renewal preview using Orders API

### Problem

This issue is to track the verification process to enable the use of [Using Orders API when previewing ineligibility for auto renewal notification AND upcoming auto renewal notification job](https://gitlab.com/groups/gitlab-org/-/epics/9047).

**Associated FF:** [`use_orders_api_preview_in_upcoming_saas_mailer`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5070)

### Testing scenarios
| Scenario | Steps | Expected result | Pass? (Staging environment) | Notes |
|----------|-------|-----------------|-----------------------------|-------|
| Upcoming auto renewal notification | 1. Start the GDK, CustomersDot and ZSim if testing in local <br> 2. Create a subscription in Zuora that has a term end date next week (set order date to last year + 1 week) <br> 3. Change linked namespace to a group in gitlab <br> 4. Wait for the order to sync, then find the order in the console `order = Order.last` <br> 5. Run `AutoRenew::SendUpcomingNotificationService.new(order: order).execute` from the console |  Sends the notification email stating card will be charged | yes |  |
| Ineligibility for auto renewal notification | follow till step 4. from above <br> 5. Turn of autopay for zuora customer <br> 6. set `eligibility_response = ServiceResponse.error(message: 'Ineligible for custom auto renew',payload: { reasons: [:auto_pay_disabled], order_id: order.id })` <br> 7. run `AutoRenew::SendIneligibleForUpcomingRenewalNotificationService.new(order: order, eligibility_response: eligibility_response).execute` | Sends the notification email stating invoice will be sent | yes | Workflow might no longer be in use. <br> `enable_sales_assisted_autorenew` ff is enabled in prod so required condition `:auto_pay_disabled` [will not be satisfied](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/services/auto_renew/eligibility_service.rb#L79). <br> Manually creating response and testing this to make sure there's no regression if the ff is turned off |

### Result

### Next steps (if any)

Story points: 2.0
[Testing] Preview reconciliation workflow using Orders API

### Problem

This issue is to track the verification process to enable the use of [Use of Orders API when sending email for upcoming reconciliation AND validating quoted invoice during reconciliation](https://gitlab.com/groups/gitlab-org/-/epics/9048).

**Associated FF:** [`use_orders_api_to_preview_quoted_invoice_amount`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5068)

### Testing scenarios
| Scenario | Steps | Expected result | Pass? (Staging environment) | Notes |
|----------|-------|-----------------|-----------------------------|-------|
| Upcoming reconciliation email  | 1. In Gitlab create a new group with 1 billable user. <br> 2. Purchase a paid plan, with subscription quantity=1. <br> 3. In customer dot rails console run <br>`order = Order.find_by_gl_namespace_id(group.id)` <br> `reconciliation = order.reconciliations.first` <br> `SendUpcomingReconciliationEmailJob.perform_now(reconciliation.id)`  | Should receive an email regarding upcoming reconciliation | yes |  |
| Reconciliation  | above steps + <br> 4. In customer dot rails console run `ReconciliationService.new(reconciliation).execute` | Should send email regarding completed reconciliation and can see an amendment to the subscription in zuora | yes |  |

### Result

### Next steps (if any)

Story points: 1.0
[Testing] Preview subscription upgrade workflow using Orders API

### Problem

This issue is to track the verification process to enable the use of 'Orders API in Preview Subscription Upgrade workflow'.

**Associated FF:** [`use_orders_api_to_preview_upgrade `](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5051)

### Testing scenarios
| Scenario | Steps | Expected result | Pass? (Staging environment) | Notes |
|----------|-------|-----------------|-----------------------------|-------|
| Upgrade Saas | 1. Create anew SaaS subscription or find an existing active subscription in customerDot <br> 2. Click on `Upgrade plan` <br> 3. Verify details | details match when ff is both enabled and disabled | yes |  |
| Upgrade SM | 1. Create anew SM subscription or find an existing active subscription in customerDot <br> 2. Click on `Upgrade plan` <br> 3. Verify details | details match when ff is both enabled and disabled | yes |  |

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Switch to JSON formatting for Puma logs

<!-- 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

Puma logs are unstructured, unlike those of Rails and Sidekiq. The benefits of structured logs goes without saying.

### Proposal

Add a JSON formatter for Puma, GitLab has one already (implemented [here](https://gitlab.com/gitlab-org/gitlab/-/blob/38bf33e1ae652b3b752557ecb5da4ecd41d74a42/config/puma.rb.example#L81) and [here](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/puma_logging/json_formatter.rb)), so it should be very easy to make the switch.

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Story points: 2.0
Fix GraphQL deprecation warnings

### Problem

We are getting two GraphQL deprecation warnings:

```
Legacy `.graphql_definition` objects are deprecated and will be removed in GraphQL-Ruby 2.0. Use a class-based definition instead.
```

```
Legacy `.to_graphql` objects are deprecated and will be removed in GraphQL-Ruby 2.0. Remove `.to_graphql` to use a class-based definition instead.
```

These are coming from `spec/support/helpers/graphql_helpers.rb`, [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/spec/support/helpers/graphql_helpers.rb#L104) and [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/spec/support/helpers/graphql_helpers.rb#L155) respectively.

### Proposal

##### Proposal 1
The only tests that use `GraphqlHelpers` is https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/spec/graphql/resolvers/subscription_spec.rb. IMO we should:

1. Move any missing test coverage from the [resolver spec](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/spec/graphql/resolvers/subscription_spec.rb) to the [request spec](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/spec/requests/graphql/subscription_spec.rb)
2. Remove `GraphqlHelpers`. This helper recreates behavior from the GraphQL gem instead of testing it directly. I don't think this is worth any potential test suite speed increase we may see from using it.

##### Proposal 2

Alternatively, we could probably pull in the latest [`GraphqlHelper` from Gitlab](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/support/helpers/graphql_helpers.rb)

Story points: 1.0
FF use of Orders API in Order Preview GraphQL endpoint

<!-- 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 [preview amendment using orders API](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4694) is merged, we can update the workflows to preview using the orders API using a feature flag to control its rollout.

This issue integrates the use of Orders API in GraphQL endpoint for Order Preview.

### 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
FF 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

Now that [preview amendment using orders API](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4694) is merged, we can update the workflows to preview using the orders API using a feature flag to control its rollout.

This issue integrates the use of Orders API in auto renewal workflow:

* Ineligibility for renewal notification job
* Upcoming notification job

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

In `AutoRenew::SendUpcomingNotificationService` and `AutoRenew::SendIneligibleForUpcomingRenewalNotificationService`, invoke `Zuora::Orders::AmendmentManagerService` if the request is to preview and FF `<FF-name>` is enabled.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
FF 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

Now that [preview amendment using orders API](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4694) is merged, we can update the workflows to preview using the orders API using a feature flag to control its rollout.

This issue integrates the use of Orders API in reconciliation workflow:

- upcoming reconciliation
- validating quoted invoice during reconciliation

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

In `SendUpcomingReconciliationEmailJob` and `ReconciliationService`, invoke `Zuora::Orders::AmendmentManagerService` if the request is to preview and FF `use_orders_api_to_preview_quoted_invoice_amount` is enabled.

### Result

Orders API is used in reconciliation workflow as a replacement to Amend API.

### Next steps (if any)

### How will we measure success?

Story points: 2.0