giseldo/neodataset huggingface dataset:
Resolver to preview seat addition

<!-- 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

In the seat purchase workflow, the customer is provided with a preview of the seat addition before confirming to purchase.

Currently, this uses the `subscription#update` endpoint with `preview: true` to obtain the invoice information.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Create a resolver that can be used to retrieve invoice details to add seats to a subscription.
Since the preview does not make any change to any objects, we do not create a mutation. In order to add seats, the [mutation](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5583) will be used.

### Result

The resolver can be used to preview invoice for a seat addition.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Manual Legacy License creation does not take custom email, company and name info

### Problem

When creating a custom Legacy License in the Admin (`/admin/license/new_license`), any values entered in the fields for email, company and name won't be reflected in the created license when a subscription ID was entered. This is because those values are always overridden in [these lines](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/fdfe35c10eb1b72120f7732d69b19cece0172180/app/models/license.rb#L313-315) which are triggered in a [before validation callback](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/fdfe35c10eb1b72120f7732d69b19cece0172180/app/models/license.rb#L85).

The [original functionality](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5412) was implemented with a select of a customer on the manual Legacy License creation page. When a customer was selected, this override would kick in and no manual values were accepted in the form.

With the transition away from customers and to billing accounts, this functionality broke because when a subscription is present, the billing account will be present as well and results in triggering the override.

### Proposal

There are (at least) two possible ways to resolve this:

1. Introduce a billing account select in the Legacy License creation form to clearly enforce the override similar to how a select existed for customer in the past ([original MR](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5412)). This also means that if no billing account was selected, the entered data from the form has to be used. 
2. Avoid overriding the three values if they were entered into the form.

### Result

Ability to manually override the email, company and name in the manual creation form for a Legacy License.

Story points: 2.0
Remove customer memoization related to billing account attrs

### Summary

Related issue: !6952

Relevant discussion: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6952#note_1332774510

For the `Customer` we memoize the `zuora_account_id` and `salesforce_account_id` values when loaded the first time from the billing account using an instance variable.

Given this memoization can happen in the same request when the associated `billing_accounts` collection for the customer can change + that instance variables are not reloaded on customer reload we end up with the wrong associated values for the entire request (the initial value).

### Porposal

Remove the memoization for `Customer#zuora_account_id` and `Customer#salesforce_account_id`.

Rollout this using the `remove_customer_account_ids_memoization` feature flag (in case we run into a significant slow down in queries). Note we are not expecting for this to impact significantly performance but want to be extra careful. We will leave the flag in place a couple of days and then drop it as part of this same issue.

### Feature rollout using `remove_customer_account_ids_memoization` feature flag

- [ ] MR removing the memoization is deployed to staging
- [ ] MR removing the memoization is deployed to production
- [ ] [Flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/206/edit) is enabled in staging (wait until next day to continue)
- [ ] [Flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/206/edit) is enabled in production (wait 1 / 2 days to continue)
- [ ] MR removing the feature flag is deployed to production
- [ ] [Flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/206/edit) is disabled for all environments
- [ ] [Flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/206/edit) is deleted

Story points: 2.0
Remove unused additional_seat_price_per_year from upgrade_amendment_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
Discovered when adding fields in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5868

The [additional_seat_price_per_year](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/4b5712225e8872d251feee1a332759c1b55aed7f/lib/zuora/responders/upgrade_amendment_response.rb#L125) in `upgrade_amendment_response` is unused. 

### Proposal
Remove the field from the file and associated tests to avoid lingering dead code. Verify the removal for both frontend and backend code.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Refactor Change Namespace FE test to not use internal wrapper.vm methods



### Problem
`components/change_namespace_form_spec.js` tests rely heavily on internal vm methods (such as `wrapper.vm.complete` and unnecessary `waitForPromises`/`nextTick`s. The internal vm behavior can be different between vue2 and vue3, so we should avoid using them. 

### Proposal
Refactor tests in `components/change_namespace_form_spec.js` to no longer use internal vm methods or unnecessary `waitForPromises`/`nextTick`s. This will assist in the Vue3 migration.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Update gem pry to 0.14.2

Update gem `pry` to version 0.14.2 to get it working with Ruby 3.2. Otherwise we have this error:

```
NameError: undefined method `=~' for class `Pry::Code'
/builds/gitlab-org/customers-gitlab-com/vendor/ruby/3.2.0/gems/pry-0.13.1/lib/pry/code.rb:342:in `<class:Code>'
/builds/gitlab-org/customers-gitlab-com/vendor/ruby/3.2.0/gems/pry-0.13.1/lib/pry/code.rb:32:in `<class:Pry>'
/builds/gitlab-org/customers-gitlab-com/vendor/ruby/3.2.0/gems/pry-0.13.1/lib/pry/code.rb:5:in `<main>'
<internal:/usr/local/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
<internal:/usr/local/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
/builds/gitlab-org/customers-gitlab-com/vendor/ruby/3.2.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
```
## Breaking changes?

None. See the changelog here https://github.com/pry/pry/blob/master/CHANGELOG.md#v0142v0142-january-9-2023

Story points: 1.0
Monitoring of ramps rollout

## Summary

This is the monitoring issue to make sure that the ramp subscriptions created in production are displayed as expected in the new subscription card design. We need a way to identify ramp subscriptions created in production. Maybe we could check with the sales team on this.  
Keep adding items to the tasks that need to be taken care in the monitoring stage i.e. post rollout of ramp subscriptions in production.

## How to Monitor

Use either of the processes below (not everyone might have access to Data Query). The output from both should be the same.

### Using Zuora Data Query

Use the following steps to check for ramp subscriptions in production:    

1. Login to Zuora production through Okta.
2. Create a new data query - https://www.zuora.com/platform/apps/data-query/queries/new
3. Query to use - `select Subscriptionnumbers, * from orders o inner join ramp r on o.Id = r.OrderId LIMIT 10`.
3. Run query.
4. Copy any 1 subscription number.
4. Search for this subscription number in Zuora subscriptions page - https://www.zuora.com/apps/Subscription.do?menu=Z-Billing.
4. Copy the corresponding Customer name.
5. Sign in to Customers Portal production as admin user through Okta.
6. Go to `Customers` tab in Customers Portal admin view.
7. Search of the copied customer name.
8. Impersonate the customer as admin to check that the ramp subscription card is shown properly with expected details and subscription management buttons hidden. Can use this [list of scenarios](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5384) to verify if the subscription card shows as expected.
9. Repeat the above steps for 5 customers.


### Using Zuora Report

Additional details in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/6129#note_1332193491.

1. Login to Zuora production through Okta.
2. Go to Reports > `Tatyana - Shared` > `Subscriptions with Ramps` > click Run Summary Report (most recently created subscriptions will be at the top).
1. Copy `Sold To: Work Email` or `Account: Name`.
5. Sign in to Customers Portal production as admin user through Okta.
6. Go to `Customers` tab in Customers Portal admin view.
7. Search of the copied customer email or name.
8. Impersonate the customer as admin to check that the ramp subscription card is shown properly with expected details and subscription management buttons hidden. Can use this [list of scenarios](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5384) to verify if the subscription card shows as expected.
9. Repeat the above steps for 5 subscriptions.

Story points: 1.0
Update specs to consume Matterhorn pricing

As part of [Matterhorn](https://internal-handbook.gitlab.io/handbook/product/pricing/matterhorn/) we are increasing the pricing of Premium plans.

Our tests assert correct price in multiple scenarios. What this means is that we have assertions that monthly price is exactly 19$. 

With https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/1117#note_1326126105+ this price is no longer correct and we should update our tests accordingly

Story points: 1.0
Avoid speculation of overages in  SM auto-renewal emails

<!-- 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/

-->

# Feature Request

## Problem

Customers are [confused](https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/920#note_1316701978) by the wording used in the renewal emails regarding overages:

> ... you may have unpaid seat overages for your instance.

## Proposal

Change the wording to avoid speculation:

> ... {+we could not determine whether+} you ~~may~~ have unpaid seat overages for your instance.

## How will we measure success?

Story points: 1.0
Update the Admin "skip email confirmation" checkbox

### Problem

Based on [feedback (external slack link)](https://gitlab.slack.com/archives/C04NTCL7465/p1679324109109919?thread_ts=1679037493.612869&cid=C04NTCL7465):

> Question on this, is the “skip email confirmation” option only relevant when updating the email address?
The current UI makes it a permanent setting, it seems, for the account. I wonder if it makes more sense to be a one-time option when making an email update?

### Proposal

~~1. Update the UI so it is only displayed when the email is updated.~~ (`rails_admin` is really restrictive about the UI changes it allows it is very difficult to introduce customizations like this.

2. :white_check_mark: Rephrase the checkbox copy to make it clear it applies to an email update.

**New copy:** `if checked when the email is updated, skips the email confirmation`

Story points: 1.0
Update help text for Customer account email address

### Problem

We currently show "We use this email for notifications about your subscriptions." for the Account details email address provided by the customer.

![image](/uploads/9a92816c107113347dd0d7fdfb9f799c/image.png)

As we are introducing `Bill To` and `Sold To` contact for the customer, we should update the help text to reflect its purpose.

FYI: [Related conversation](https://gitlab.com/gitlab-org/gitlab/-/issues/330608/designs/Link_CDot_account_to_GitLab.com_account_with_the_same_email__when_CDot_account_is_already_linked_to_a_different_GitLab.com_account__AND_CDot_account_has_active_subscriptions_.png#note_1296416109).

### Proposal

Update help text for Customer account email address to reflect its purpose. This should be made conditional, if a GitLab.com account is connected or not.

#### Connected GitLab.com account:

> This is your Customers Portal account email address and is linked to your GitLab.com account.

#### No connected GitLab.com account:

> This is your Customers Portal account email address.


### Result

Customers are better informed about the different purposes of Account email, `Bill To` and `Sold To` email.

Story points: 1.0
Inconsistency - Showing cents in some places and not in others

<!-- 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 not being consistent in what we show our users. In some places we show cents `41.04` but in other places we round to a whole number. From a brief glance at the code this looks like inconsistent use of the `formatMoney` function.

| Page and decimal | Screenshot |
| ------ | ------ |
| New subscription - 2 decimals | ![Screenshot_2023-03-17_at_12.36.08](/uploads/e72f4d19fbd0fe0d88468eaa130c07ce/Screenshot_2023-03-17_at_12.36.08.png) |
| Renew - 2 decimals |  ![Screenshot_2023-03-17_at_12.37.53](/uploads/12d47db4f500ed2dbb64a9b45d2acf14/Screenshot_2023-03-17_at_12.37.53.png)|
| Subscriptions overview - 0 decimals | ![Screenshot_2023-03-22_at_9.56.08_AM](/uploads/2598aac37e7cca04f8ddd06de77da022/Screenshot_2023-03-22_at_9.56.08_AM.png) **Zuora data** ![Screenshot_2023-03-22_at_9.56.39_AM](/uploads/30a26a03bcdc15a52df308ca29f390d7/Screenshot_2023-03-22_at_9.56.39_AM.png)|



### Proposal

* Audit usages of `formatMoney` (also looks like we've got components where we only import the function)
* Consistently use 2 decimals - Can possibly be enforced with a helper function

### Result

Consistency in what we display

### Availability and Testing
E2E tests `number_to_currency` options will need to be updated in some places as well. A few key areas to note:
- `qa/page/component/ramp_subscription_card.rb` - remove `precision: 0`, so that whole prices will have .00 for cents
- `qa/vendor/gitlab/page/component/order_summary.rb` - remove `strip_insignificant_zeros: true`, so that trailing zeros are not stripped

Story points: 2.0
Update gem date to 3.3.3

# Summary

Installation (building) of [gem `date`](https://rubygems.org/gems/date) current fails on Ruby 3.2 with the following error:

```
date_core.c:7289:5: error: implicit declaration of function 'rb_check_trusted' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    rb_check_trusted(self);
    ^
```

Update to the latest available version - 3.3.3.

## Breaking changes?

None. Link to the changelog - https://github.com/ruby/date/releases/tag/v3.0.0

Story points: 1.0
Update gem pg to 1.4.6

# Summary

Installation (building) of [gem `pg`](https://rubygems.org/gems/pg) current fails on Ruby 3.2 with the following error:

```
pg_result.c:1590:58: error: use of undeclared identifier 'rb_cData'
        rb_cPGresult = rb_define_class_under( rb_mPG, "Result", rb_cData );

```

Update to the latest available version - 1.4.6.

## Breaking changes?

[None.](https://github.com/ged/ruby-pg/blob/master/History.md#v123-2020-03-18-michael-granger-gedfaeriemudorg)

Story points: 1.0
Implement error codes for purchase flow errors

<!-- 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 errors are matched using strings, they are quite fragile to changes in the backend and string mismatches. An example of this is when the `{"email": ["has already been taken"]}` error was translated to the [description here](https://gitlab.com/gitlab-org/gitlab/-/issues/330608#initial-problem) with a different character, leaving the error handled sub-optimally.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Implemented error codes for each of the [purchase errors](https://gitlab.com/groups/gitlab-org/-/epics/9543#proposal) as [discussed here](https://gitlab.com/groups/gitlab-org/-/epics/9543#note_1221457048) and [here](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/109662/diffs#note_1274594411).

Story points: 5.0
Creation of the BillingAccountContact model

This issue is part of the creation and implementation of the `BillingAccountContact` model to cache the "Bill to" and "Sold to" Zuora contacts:

1. [Rename current BillingAccountContact helper class](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/6056) (closed)
1. **Creation of the `BillingAccountContact` model** :point_left: You are here
1. [Implementation of `BillingAccountContact` and sync with Zuora](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/6067)
1. [Data backfill for existing `BillingAccount` objects](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/6068)

### Proposal

This issue tracks effort related to the creation of the `BillingAccountContact` model. This model will hold `Zuora::Contact` data as well as the `zuora_contact_id` related to the object we want to save.

A `BillingAccountContact` object will ultimately be the SSOT for customer contact details, which means that contact detail fields in `Customer` should also be present in `BillingAccountContact` (we may want to be consistent with the new Presenter introduced via [this MR](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6838)). 

`BillingAccountContact` objects will only be created to hold Bill to and Sold to contact data, given a `BillingAccount` object. This means that `BillingAccount#sold_to` and `BillingAccount#bill_to` references will have to be added: this mimics the architecture behind `Zuora::Account` (ie. access of these contact objects via `zuora_account.bill_to` and `zuora_account.sold_to`, even if they are the same object (which is often the case))

Work on this issue should not be about implementation.

### Result

Passing tests.

Story points: 3.0
Rename current BillingAccountContact helper class

This issue is part of the creation and implementation of the `BillingAccountContact` model to cache the "Bill to" and "Sold to" Zuora contacts:

1. **Rename current BillingAccountContact helper class** :point_left: You are here
2. [Creation of the `BillingAccountContact` model](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/6066)
3. [Implementation of `BillingAccountContact` and sync with Zuora](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/6067)
4. [Data backfill for existing `BillingAccount` objects](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/6068)

### Problem

There's a `BillingAccountContact` class that's currently being called from `BillingAccount#contact`. 

### Proposal

We want to make the `BillingAccountContact` class name available for the new model. This issue tracks effort to rename the existing `BillingAccountContact` into something else.

### Result

Passing tests.

Story points: 2.0
QSR banner should only display if QSR is enabled

<!-- 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

Offline Cloud License customers are seeing upcoming QSR banners in their instance, while not being on QSR or not necessarily having exceeded their seat count.

The work for QSR's for Offline customers has not yet been completed by ~"group::billing and subscription management" (see [related epic](https://gitlab.com/groups/gitlab-org/-/epics/7471)). However, we recently became aware that SM customers on an Offline license are seeing QSR upcoming banners.

~"group::provision" [setup a banner](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3355) a year back for Offline customers notifying them of an upcoming QSR: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3355/designs/Automated_license_file_quaterly_reconciliation_alerts.png

These are shown 14 days prior, 7 days prior and 1 day after the reconciliation due date. These were established with the assumption of QSR support for offline customers.

However, the banner text states `You have more active users than your license allows for. (or than are allowed by your license.) Before \*\*date\*\* you must get reconciled? GitLab must reconcile your subscription/license?` - without ever having any awareness if the user has *actually* exceeded their seat count.

## Proposal
Update the banner logic to only display if `turn_on_seat_reconciliation__c` is `Yes` - otherwise this should not be shown.

Story points: 1.0
Collect all deprecation warnings for Ruby 3

Ruby 3 and 3.2 has many breaking changes when it comes to Ruby 3 itself.
To provide a smooth update, we need to collect all deprecations in our code base and resolve them one by one.

Run CI or all tests with `env RUBYOPT="-W:deprecated` to get all places with deprecations.

Adopting the workflow from GitLab https://gitlab.com/gitlab-org/gitlab/-/issues/257438

Story points: 1.0