giseldo/neodataset huggingface dataset:
[Placeholder] Implementation of displaying ramps 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
Placeholder issue to indicate the tentative weight for implementation of displaying ramps subscriptions.

### 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: 0.0
Issue breakdown to display ramps 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
Placeholder issue to breakdown the implementation to display ramps subscriptions.
### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Subscription sync alert banner no longer presents after clicking on Sync subscription details button

<!---
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

## Summary

Subscription sync alert banner no longer presents after clicking on Sync subscription details button

This is causing self-managed e2e test job to fail - https://gitlab.com/gitlab-org/customers-gitlab-com/-/pipelines/717640365


## Steps to reproduce

1. Activate local gdk with an valid cloud activation code
2. Click `Sync subscription details` button
3. Subscription sync alert banner shows and disappears

## Screenshot
![sync_banner](/uploads/bec336cfab997516e80a05c28e1f698e/sync_banner.gif)

## Proposal
Resolve banner issue to ensure it is displayed correctly.

Story points: 5.0
POD for Partners: Add Invoice Owner CC to SaaS Vouchers

<!-- 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/-/issues/3372+ implemented CC's to partners on all Self Managed mailers to improve visibility into the license process. We should do this same thing for SaaS mailers, as partners have an interest in this as well.

### Proposal

- Introduce a voucher email to be sent along the notification about SaaS purchases initiated in SFDC ([`CustomerMailer#gl_com_purchase_from_sf`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/b54a3198a732d5b2662928acd86f4fba6d45a9f8/app/mailers/customer_mailer.rb#L35)). 

- Include the `Sold To Contact` email address of the quote's `Invoice Owner` as CC as well.


<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result
Partners are aware of their customer's SaaS provisioning real-time.

Story points: 2.0
Orders created without some subscription data

### Problem

It was discovered, as discussed in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5249#note_1197338320, that there are many Orders in production associated with a subscription (e.g. have `subscription_name` present) but are missing many subscription-related attributes like `start_date`, `end_date`, and `subscription_id`.

We [determined the problem](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5249#note_1200272445) to be with [this line](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/70d456ed746c25b659f2b70052f28df936353b42/app/controllers/subscriptions_controller.rb#L63) in the `SubscriptionsController#edit` action.  If the order was not already created at this point, one would be created but not with all the necessary subscription info.

### Proposal

We should replace this logic in the controller to use the `CreateOrderService` which we know creates an order with all the necessary subscription data points.  This is used in other places in the app to create orders.

Story points: 1.0
Clean up portal_price_before_proration & portal_proration_credit calculation from backend

<!-- 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

After https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5106 we will no longer be using these values in the frontend in CustomerDot and Gitlab. We can remove these calculations so that we don't have dead code.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

1. These values are being passed in `orderPreview` graphql query to gitlab. Remove these values from the endpoint (& from schema in gitlab)
2. Remove the calculations from `amendment_base_service.rb` & `preview_service.rb`

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Refactor Customer/Account form

## Proposal

Once the `account_data_structure` flag is enabled/stable and we start working towards https://gitlab.com/groups/gitlab-org/-/epics/8951+, the Account/Customer form in CustomersDot should be in a position to be refactored in a few ways.  Please see https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6037#note_1196864310 for more background.

Here are a few things we can consider:
1. ~~Avoid showing or updating `Customer.company` in this form.  At this point, `BillingAccount.zuora_account_name` should be the attribute used across the app.  There should be no need to maintain `company`~~. EDIT: follow-up in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5656
2. `UpdateContactService` is called only from a Customer model callback. It's only triggered when the virtual attr `sync_with_zuora` is set, which only happens [in the RegistrationsController](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/37933553209ad5c0b13c33ab2a786200c2aa4d27/app/controllers/registrations_controller.rb#L36). It would be nice to avoid this callback altogether and move this logic to the `RegistrationsController`. This service could be refactored (and renamed) to clarify it's scope. 

### Follow up

The following discussion from !6037 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6037#note_1196864310):  (+4 comments)

    > **Suggestion:** What do you think about updating the BillingAccount last (or at least after the Zuora account?  Just want to avoid a situation where the BillingAccount is updated but something fails updating the ZuoraAccount and the two are not in sync.

The following discussion from !6355 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6355#note_1246463812):

    > **Thought (non-blocking):** There are some known problems with this service, one of which is that it's not transactional. If the zuora account update fails on this line, it seems like it will continue to update the billing account and zuora contacts, but that might not be ideal.

Story points: 3.0
Drop PSQL 10.17 from supported tools

We migrated all our environments to CloudSQL on GCP. Both production and staging environments are on PSQL 12 now.
That means we can safely drop PSQL 10 from the list of supported runtimes and tools. Currently we have it in the `.tool-versions` file and in order to remove it from this file we should create or document convenient way for upgrading existing databases of team members (located in `./db/postgesql`).

## How to upgrade local PSQL database from 10 to 12

Given the database is running in `./db/postgresql` we can perform the following steps to upgrade it:

1. Stop the application
2. Stop the PSQL master:

   ```shell
   asdf exec pg_ctl stop -D ./db/postgresql
   ```

3. Demote the data folder to old cluster:

   ```shell
   mv ./db/postgresql ./db/postgresql-10
   ```

3. Activate PostgreSQL 12 binaries:

   ```shell
   asdf shell postgres 12.12
   ```

   Verify it with `psql --version`. This command must output `psql (PostgreSQL) 12.12`

4. Check the upgrade path:

   ```shell
   asdf exec pg_ctl initdb -D ./db/postgresql-12
   asdf exec pg_upgrade --old-bindir=$(asdf where postgres 10.17)/bin --new-bindir=$(asdf where postgres 12.12)/bin --old-datadir=./db/postgresql-10 --new-datadir=./db/postgresql-12 --check
   ```
   
   Look for the `*Clusters are compatible*` line at the end. If not, please report in this issue.

5. Do the upgrade:

   ```shell
   asdf exec pg_upgrade --old-bindir=$(asdf where postgres 10.17)/bin --new-bindir=$(asdf where postgres 12.12)/bin --old-datadir=./db/postgresql-10 --new-datadir=./db/postgresql-12
   ```

6. Start the new PSQL 12 master:

   ```shell
   asdf exec pg_ctl start -D ./db/postgresql-12
   ```

7. Generate minimal optimizer statistics to verify the new database: `./analyze_new_cluster.sh`
8. Run the script to delete the old database data: `./delete_old_cluster.sh`
9. Move the new database cluster to the old location `./db/postgresql`:

   ```shell
   asdf exec pg_ctl stop -D ./db/postgresql-12 && mv ./db/postgresql-12 ./db/postgresql
   ```

10. Remove migration files: `rm analyze_new_cluster.sh delete_old_cluster.sh update_extensions.sql`
11. Start the new database cluster and verify your local copy of CustomersDot still works:

   ```shell
   asdf exec pg_ctl start -D ./db/postgresql
   ```

Story points: 1.0
Add logging in CloudActivations::ActivateService when seat link creation failed

### Problem

When an activation of a self-managed instance with an activation code failed because of an error while creating the seat link data, the error is [logged by the SeatLinkCreateService](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e9eaf1283947f750b763c9e179626f0bbb341284/app/services/seat_link_create_service.rb#L24-27). The `SeatLinkCreateService` is used in other workflows like the daily seat link sync. This makes debugging for errors during an activation a little bit harder since the `CloudActivations::ActivateService` [does not log anything](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e9eaf1283947f750b763c9e179626f0bbb341284/app/services/cloud_activations/activate_service.rb#L89) about this with its own context and the errors have to be looked up with a `SeatLinkCreateService` context. 

### Proposal

Even though the [`SeatLinkCreateService` has logging for an unsuccessful processing](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e9eaf1283947f750b763c9e179626f0bbb341284/app/services/seat_link_create_service.rb#L24-27), it might make sense to add additional logging in the 
`CloudActivations::ActivateService` when the [response of the `SeatLinkCreateService` is unsuccessful](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e9eaf1283947f750b763c9e179626f0bbb341284/app/services/cloud_activations/activate_service.rb#L89). This could make debugging errors during an activation a bit easier and quicker since we would be able to actually find error loggings for the `CloudActivations::ActivateService` even when the actual error happened in the `SeatLinkCreateService`.

### Result

Additional error logging that helps with debugging errors during activation quicker since we'll be able to find something specifically linked to the activation when the seat link creation failed.

Story points: 2.0
Ensure to log service class name in `log_warn` and `log_error`

When checking logs, sometimes it is tricky to know where does an error come from. One example is https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5264#note_1194023547.


ATM we only log service class name in [log_info](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/96fcaba30e1df12ecf6f5ddd1cb88923455fd56b/lib/gitlab/logger_helpers.rb#L7-9). 

```
    def log_info(message, extra: {})
      log(:info, "#{self.class.name}: #{message}", extra: extra)
    end
```

I think we should ensure we log the `self.class.name` for [log_warn](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/96fcaba30e1df12ecf6f5ddd1cb88923455fd56b/lib/gitlab/logger_helpers.rb#L11-14) and [log_error](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/96fcaba30e1df12ecf6f5ddd1cb88923455fd56b/lib/gitlab/logger_helpers.rb#L16-18) as well.


### 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
Purchase fails with error: <PaymentMethodID> is not a valid hosted payment method.

<!---
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

## Summary

Sometimes purchases fail with the generic error `An error occurred in the purchase step. If the problem persists please contact support at https://support.gitlab.com.` but when we check the logs we find an error log that states:

```
<PaymentMethodID> is not a valid hosted payment method.
```

## Relevant logs and/or screenshots

Example [GCP Logs (internal)](https://console.cloud.google.com/logs/query;cursorTimestamp=2022-12-01T08:57:39.987Z;query=%22A-S00041396%22%0Atimestamp%3D%222022-12-01T08:57:39.987Z%22%0AinsertId%3D%228lrda1g2ua8331%22;timeRange=P7D?project=gitlab-subscriptions-prod)

## Workarounds

1. Use an incognito window to make the purchase (worked for 1)
2. Use a different device i.e. mobile phone (worked for 4)

## Reported examples

1. https://gitlab.zendesk.com/agent/tickets/335749
1. https://gitlab.zendesk.com/agent/tickets/346748
1. https://gitlab.zendesk.com/agent/tickets/350388
2. https://gitlab.zendesk.com/agent/tickets/356964 (Purchase via Chrome incognito/private mode didn't work for this customer; trying on Chrome Mobile worked)


<!---
Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 5.0
Enable `try it` on marketplace openAPI document page

We have openAPI document for marketplace: 
- internally viewable from gitlab blob viewer: https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/doc/api/openapi.yaml. This requires CustomersDot repository access, as CustomersDot is a private project
- publicly viewable from https://customers.staging.gitlab.com/openapi_docs/marketplace and https://customers.gitlab.com/openapi_docs/marketplace

For the publicly document(https://customers.staging.gitlab.com/openapi_docs/marketplace and https://customers.gitlab.com/openapi_docs/marketplace), it will be helpful to allow `Try it out` from this page. I think this will be convenient for marketplace partners, and it will help to reduce the integration frictions.

### 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
[SM] Avoid license notification when provisioning is not needed when ramps begin

### Problem

Once https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5247 is completed, all ramp subscriptions will have licenses generated for the full subscription term.  For example if a 3 year subscription might have 3 one year ramps.  Any licenses generated for this subscription would be created for the full 3 years.

However, as discussed in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4295#note_1190124058, there may be times when nothing changes to the subscription when a new ramp starts that affects provisioning (e.g. the quantity does not change).  If that's the case, a callout will still be sent to CDot to provision for the new ramp.  An identical license would generated and notification sent to the customer, leading to confusion as a new license would not be necessary.

### Proposal

Let's update CDot to avoid generating a new license and avoid notifying the customer when this scenario arises.  

This filtering logic probably will need to be done when processing the callout. It might be similar to what CDot for [the Seat Link Service](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/4ae39fa629f11d88d5575837412df990e624b9a5/app/services/seat_link_create_service.rb#L193). The service [compares the most recent license to the new license](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/3e8889422f9bc05f57cb205fb025364b28ccdcef/app/services/build_license_from_subscription_service.rb#L45) and only generates the new one if needed.

Story points: 3.0
[Follow up] Update usage of allow_buy_subscription method

<!-- 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
Follow up issue from this MR conversation - https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5958#note_1188823085.

### 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: 0.0
Simplify support of multiple class objects in VoucherMailer

### Problem

As part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5929#note_1180208624, the logic to find the email, name and company of the recipient as well as the log info in the `VoucherMailer` was getting too complex. This is because there are now three classes (`License`, `Subscription` and `Customer`) that are supported by the `VoucherMailer`. In the linked thread there were a few options that were discussed. But [one](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5929#note_1182039949) seemed like the way to go.

### Proposal

All three classes, `License`, `Subscription` and `Customer`, used in the `VoucherMailer` should respond to the same methods. E.g. currently only `License` and `Customer` respond to an `email` method and `Subscription` has to use the `sold_to_contact&.work_email` methods to get to the same info. If all three classes respond to the same method name, a single object could be provided to the VoucherMailer and removes all the current complexity by calling the method names that are supported by all three classes.

### Result

Remove complexity around the logic to find the email, name and company of the recipient as well as the log info in the `VoucherMailer`.

Story points: 2.0
Use constants for mailer subject

### Problem

In a [review comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5929#note_1182039948), it was suggested to use constants for the mailer subject to reuse them in voucher mailer counterparts. This will ensure that the email subject is always the same for the voucher email (the email that goes to SFDC) as in the actual email that goes out to the customer.

### Proposal

Replace hard coded subjects in mailers with constants and reuse them in existing voucher mailers.

### Result

Consistency in mailer subjects.

Story points: 2.0
Follow-up from "Persist billing account via FindOrCreateCustomerService"

The following discussion from !5807 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5807#note_1164663028):  (+3 comments)

    > **Suggestion (non-blocking):** I suppose we could add some specs for if the `UpdateBillingAccountService` service returns an error result, just to make sure the compose works as we'd expect.  Maybe something to think about for a follow-up?

Story points: 1.0