giseldo/neodataset huggingface dataset:
Rely on https://gitlab.com/gitlab-org/gitlab-build-images to install node + headless chrome for CI builds

<!-- 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/

-->

Half-step towards https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/834

We're currently installing custom dependencies like node, yarn, and headless chrome via a custom shell script https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/bd7286b17af7db1b11de5fa12f929085b539f8a3/scripts/prepare_build.sh

Since the Customer Portal has much the same dependencies as GitLab does, we can piggyback on the [gitlab-build-image](https://gitlab.com/gitlab-org/gitlab-build-images ) from there.

This should result in faster builds, and more reliable installs of headless chrome, so we do not end up [with these sort of workarounds again](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1423)

Story points: 2.0
Handle new throughput labels in Dangerfile for customers-gitlab-com

### Problem

`backstage` is being deprecated in favor of new scoped `feature::` and `tooling::` labels.

See: 

1. https://gitlab.com/gitlab-org/quality/team-tasks/-/issues/488
2. https://update-throughput-backstage.about.gitlab-review.app/handbook/engineering/management/throughput/index.html#deprecated-types (Review app)

### Proposal

### Result

### Next steps (if any)

Story points: 1.0
Remove ability to select ACH and Wire from payment method type

## Summary 

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1024 we intended to remove the ability to select ACH as a payment type in the customers portal. However the value still exists when attempting to make a purchase over a threshold.

### Examples

![Screen_Shot_2020-07-02_at_16.33.44](/uploads/fc397910a5926c05c32fe212bbe5b9e8/Screen_Shot_2020-07-02_at_16.33.44.png)

![Screen_Shot_2020-07-02_at_16.27.32](/uploads/d554fd5585ed73674b7829ed44e297be/Screen_Shot_2020-07-02_at_16.27.32.png)

#### When you attempt to select an option, you then receive this message and subsequent error (reported [here](https://gitlab.zendesk.com/agent/tickets/162819)):

![Screenshot_2020-07-02_at_22.00.21](/uploads/632235a49be4c725a425e3253632583b/Screenshot_2020-07-02_at_22.00.21.png)
![Screenshot_2020-07-02_at_22.00.28](/uploads/cec11e2cdd0accb9b1aa5ae7241f8494/Screenshot_2020-07-02_at_22.00.28.png)

## Proposal

Finance has [confirmed](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1644#note_372889179) that we should only offer credit card payment in all purchase flows regardless of threshold.

Story points: 3.0
Store `seats_currently_in_use` field in gitlab.com `subscription` table

<!-- 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

The Data team needs to be able to replicate the GitLab UI Billing/Usage values that Customers/Users see on the GitLab UI into internal reports (for Sales, Product, etc) from the data warehouse. To ensure one SSOT for these calculations, it would be ideal that these values are stored in the same location at the same data granularity. 

This issue specifically tracks storing the `seats_currently_in_use` field in gitlab.com `subscription` table. I will leave it up to the person who picks up this ticket to decide if this issue should also track making the UI read and use this value or if that should be a separate issue. Thank you for your help! 

FYI @amandarueda , @jbrennan1 , @derekatwood , @jeromezng 

### Proposal


Currently, the `max_seats_used` is stored into the `gitlab_subscriptions` table [via this cron job](https://gitlab.com/gitlab-org/gitlab/-/blob/c086bd8f75537a7f73fc386f2053962b389dc990/ee/app/workers/update_max_seats_used_for_gitlab_com_subscriptions_worker.rb). It would be ideal if this cron job also stored the other values on the [billing page](https://gitlab.com/gitlab-data/analytics/-/issues/5084/designs/Screen_Shot_2020-06-15_at_5.07.01_PM.png) into the datawarehouse at the same time and that the UI was retrieving this value so that there can be more consistency across systems in terms of our internal and external reporting of this value. 


### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Consolidate on pattern for product copy place and presenting

<!-- 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

Some background: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1581#note_372289528

In our `/plans` page we've got product specific copy; for example "1000 CI minutes".

We've also got product specific copy living on the frontend in https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/frontend/javascripts/purchase/products.js

Additionally there's quite a lot of copy that's living in HAML templates or Vue templates.

This means that updating copy can mean touching multiple different files, and that copy can get out of sync.

### Proposal

We should decide on some guidelines on when a copy should be pulled to a central place, and when it's fine to have it live in templates.

* When should copy be pulled to a presenter (worth taking inspiration from https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/presenters/README.md#when-to-use-a-presenter)
* When should copy live in the Vue template?
* When should we pull data directly from Zuora?
* Should some of this live in a database so we do not need to run a deploy to update copy?

Story points: 1.0
Follow-up from "Add service to create Salesforce Quote Amendment"

The following discussion from !1496 should be addressed:

- [ ] @alexbuijs started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1496#note_361526697):  (+2 comments)

    > Maybe you could expand the `sf` part of this method name to `ensure_presence_of_salesforce_quote`? It is a bit more descriptive that way.

Story points: 1.0
Ensure `gl-link` not having it's own font-size won't break Customers

<!-- 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/

-->

See https://gitlab.com/gitlab-org/gitlab-ui/-/issues/605 and https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1159#note_371241476 for more context.

The inner workings of `gl-link` font size is changing. 

> In `gitlab.com` update all existing instances of `gl-link` to add a `gl-font-base` utility class. This way, we're guaranteed the preexisting behavior is preserved in `gitlab.com` (and we can slowly migrate away from it)...

We need to do the same in Customers.

With 12 instances at the time of writing this shouldn't be the biggest lift

```
~/workspace/customers-gitlab-com staging
❯ git grep gl-link | wc -l
      12
```

Story points: 1.0
Data Cleanup: Credit card on file without default setting

## Summary

Somehow, customer records which have at least one credit card on file have gotten into a state where there is no default credit card indicated. This causes a purchasing error for users.

## Proposal

For this issue, we need to find all the data records in this state and handle them accordingly.

We should query for all customer records which have:

1. an active subscription
1. no default payment method
1. autorenew set to true

For these results we should:

1. set autorenew to false

For the results where there are more than one credit card on file:

1. Produce a report which includes:
     - Customer record link to customers portal
     - Email address associated with customer record
     - Name associated with customer record
     - Company associated with customer record
     - SFDC ID
     - Zuora ID
     - Subscription number
     - Products in subscription
     - Subscription end date

Story points: 2.0
Improve purchase error when no default credit card is on file

## Summary

When a user attempts to make a purchase in the customers portal and a credit card is on file but is not marked as "default", we display `Electronic payment needs electronic payment method` as an error, which is not helpful. 

![image__1___1_](/uploads/8dab983db2c467cc5a57d9651c4eef99/image__1___1_.png)

## Proposal

We should display a helpful message which directs the user how to solve the issue.

To solve the issue, the user needs to edit the existing credit card and mark it as `default` or create a new credit card record and mark it as default.

Story points: 1.0
UX: How should we display pricing information related to purchases?

## Summary

While working [this issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1560), we discovered a use case (plan upgrades) which we determined needed an additional level of pricing detail (the proration credit) that we do not currently display. 

In following this discussion, we determined that we would likely need to mimic the line-level detail on invoices in the subscription card to adequately display the activity. 

This led me to wonder why we are displaying pricing in the subscription card at all? I am not sure this data is commonly used by customers, especially since it is incorrect today and we don't get complaints about it. 

Perhaps we should spend effort on making the Invoices page more useful (collated by subscription, provide an ability to expand and view details, etc), rather than building pricing out in the subscription card.

I'd like UX to dig into this and provide a recommendation. Since we've removed the pricing from the subscription card, I'd like to get this follow-on work in pretty quickly.

Story points: 2.0
SPIKE: Decommission the EULA acceptance process in customers

## Summary

In a decision made [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1360#note_368446506) we will no longer require a manual EULA process. As a result. We need to decommission the processes involved, including the templates, the emails to user/reseller/SFDC. We should retain any acceptance data previously obtained for a period of _tbd_ in case it is needed by the legal team.

This is a research issue to identify, create and weight issues for the individual tasks required to decommission the customers portal EULA processes.

We will schedule the dev issues created for %"13.5"

Story points: 2.0
[Deprecate Zuora SOAP] Remove SOAP code related to payment methods

### Problem
Now that the Zuora REST update is complete and the SOAP code is no longer needed, we can remove all the legacy Zuora SOAP code from the application.  One place that was missed during the initial deprecation work was code related to payment methods.

### Proposal
We can remove the Zuora SOAP API code and related feature flags. This issue focuses on cleaning up the SOAP logic and feature flags related to the payment methods which was added in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/620.

The [`PaymentMethodPresenter` also has code](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/75cf2267f33f0b34e5c25834e34d8f489c1cfc25/app/presenters/payment_method_presenter.rb#L35) that should be cleaned up as part of this issue.

If there are any other places that check for `Feature.enabled?(:zuora_rest_api)` we should consider removing them, either in this issue or a separate issue.

Story points: 2.0
Prefer `RSpec.describe` over `describe` in top-level namespace

### Problem
The GitLab development docs were updated recently to prefer `RSpec.describe` over `describe` in top-level namespace.  It is [referenced here in the docs](https://docs.gitlab.com/ee/development/testing_guide/best_practices.html#general-guidelines). This is a best practice to avoid a monkey patch and will be removed in RSpec 4.0.

References:
- https://gitlab.com/gitlab-org/gitlab/-/issues/220018
- https://gitlab.com/gitlab-org/gitlab/-/issues/220218


### Proposal
We should update all specs to use `RSpec.describe` at the root level and disable the monkey patching going forward.  See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/220018) for more information for how this was accomplished in GL.

Story points: 1.0
Consider using IronBank's local records feature to improve performance

### Problem
There are possibly 2 problems solved by this proposal:
1. The Customer Portal commonly communicates with Zuora which can become a bottleneck for performance.
1. Plans are preloaded during the initialization of the Rails application which is a blocker for moving the Customer Portal app to Auto Devops.  Check out !525 for more details.

### Proposal
We should investigate using [the "local records" feature in IronBank](https://github.com/zendesk/iron_bank#local-records) to provide a caching layer for Zuora objects that don't commonly change.  According to the [IronBank docs](https://github.com/zendesk/iron_bank#local-records):

> If your product catalog does not change often, you may want to export it locally so that product catalog and related object queries look for local records first, then fallback to the API if no records are found.
> 
> You can export your product catalog locally using the LocalRecords class:
> ```
> # Save CSV files in the directory specified by `config.export_directory`
> IronBank::LocalRecords.export
> ```

With this change, we might be able to refactor or completely remove the eager loading of plans (defined [here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/4ff55c5197239fa25e037f3749d9af1666804e9e/app/models/plans_finder.rb#L19) and initialized [here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/8c0c8b6c20692479ea8d9482721465ebb8f6aba6/config/application.rb#L69)

### Result
A cleaner initialization and more performant app.

Story points: 3.0
Investigate card decline issue

<!---
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!
--->

### Summary

Recently, we have seen several tickets where customers are experiencing credit cards being declined even though the card works on other services. Customers also try to use different cards but seems like most of the time different cards did not resolve the issue. Since everything is not clear as we cannot find anymore information in sentry, please kindly investigate this issue.

### Steps to reproduce

N/A

### What is the current *bug* behavior?

Credit card is declined while try to make a purchase on customer portal even though it's working on other service.

### What is the expected *correct* behavior?

If the card work with other services, it should work on customer portal.

### Relevant logs and/or screenshots

- Sentry issue: [CUSTOMERSGITLABCOM-2NZ](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1181887/?referrer=gitlab_integration)

Possible related issue:

- Sentry issue: [CUSTOMERSGITLABCOM-3BM](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1531808/?referrer=gitlab_integration)

### Workarounds

(Ways to get around the issue)

### Reported examples

1. https://gitlab.zendesk.com/agent/tickets/158827
1. https://gitlab.zendesk.com/agent/tickets/160371
1. https://gitlab.zendesk.com/agent/tickets/160087
1. https://gitlab.zendesk.com/agent/tickets/162539
1. https://gitlab.zendesk.com/agent/tickets/165580 customer mentioned they have some temporary cards

<!---
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
Investigate and fix intermittent failures in payment_method spec

The following discussion from !1552 should be addressed:

- [ ] @jejacks0n started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1552#note_364813747):  (+2 comments)

    > @rhardarson looks like we have a flakey test with https://gitlab.com/gitlab-org/customers-gitlab-com/-/jobs/603585348 -- do you know what that might be about?
    > 
    > Also: https://gitlab.com/gitlab-org/customers-gitlab-com/-/jobs/603643658

Very similar to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1511

We're seeing the feature spec `./spec/features/payment_methods_spec.rb` fail every once in a while.

After the fact it's pretty difficult to figure out what went wrong.

We need to identify what's the cause of this flakiness.

* Race condition in spec?
* Non-deterministic behaviour?
* Is the spec correct but the code itself is flaky?
* Is VCR not matching HTTP requests?
* Is this because it's making real HTTP requests to Zuora? Can we add more VCR coverage then?

Story points: 5.0
Use spacing utilities from GitLab UI in CompanyDetails

The following discussion from !1364 should be addressed:

- [ ] @ekigbo started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1364#note_357623676):  (+2 comments)

    > I think we can replace these with their `gl` equivalents, :thinking: ?
    > 
    > ```suggestion:-0+0
    >     <div class="gl-display-flex gl-justify-content-space-between gl-mb-5">
    > ```

Story points: 2.0
Follow-up from "Improve order -> namespace resolution logic"

The following discussion from !1529 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1529#note_364083877): 

    > **Suggestion (non-blocking)**: We could extract part of this into a method called `gitlab_namespace`.  This method could do the lookup with the list service and return the one that matches the `gl_namespace_id`.  The main advantage is easy reuse of the gitlab namespace.
    > ```
    > def gitlab_namespace
    >   return nil if gl_namespace_id.blank?
    > 
    >   @gitlab_namespace ||= begin
    >     namespaces = Gitlab::Namespace::ListService.new(customer).execute || []
    >     # "to_s" the id from gitlab because we store ours as strings. :joy:
    >     namespaces.find { |ns| ns.id.to_s == gl_namespace_id }
    >   end
    > end
    > ```
    > 
    > That would just leave this method much simpler, maybe something like:
    > 
    > ```
    > def current_number_of_users
    >   return 0 unless gitlab_namespace
    > 
    >   gitlab_namespace[:billable_members_count) || 0
    > end
    > ```
    > 
    > Since this is not needed yet, I'm happy not doing it now.  Mostly just mentioning it so that I can create a follow up issue for it. :smile:

Story points: 3.0
FF use of Orders API for subscription update

<!-- 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 subscription update workflow.

The following business scenarios need to be implemented:

- Add CI minutes
- Add seats
- Add storage
- Renew subscription
- Renew subscription with true up
- Renew subscription with upgrade

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

In `SelfService::Subscriptions::UpdateService`, invoke `Zuora::Orders::AmendmentManagerService` if the request is to preview and FF `use_orders_api_to_preview_amendment` is enabled.

### Result

Orders API is used to preview subscription update.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
FF use of Orders API for subscription upgrade

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

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 upgrade workflow.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

In `Gitlab::UpgradeSubscriptionPlanService`, invoke `Zuora::Orders::AmendmentManagerService` if the request is to preview and FF `use_orders_api_to_preview_amendment` is enabled.

### Result

Orders API is used to preview subscription upgrade.

### Next steps (if any)

### How will we measure success?

Story points: 2.0