giseldo/neodataset huggingface dataset:
[REST Update] Turn on `zuora_rest_api` feature flag by default in tests suite

### Problem
Now that we are in a position to have the `zuora_rest_api` feature flag on in production, we need to ensure the test suite runs alls specs successfully under this scenario.

### Proposal
Turn on the `zuora_rest_api` feature flag by default in `spec_helper.rb`.  Address any broken tests that result from the feature flag being on.

### Result
Better test coverage of the `zuora_rest_api` feature.

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Hide ACH in Customer Portal

## Overview
We want to hide ACH as an option for payment for customers in the customer portal. Per our billing team we have not seen an ACH transaction in the last couple years and we don't want to invest the work to bring it over to pajamas. 

We also will likely need to remove it as part of https://gitlab.com/gitlab-org/customers-gitlab-com/issues/786 so hiding it now will (1) allow us to not invest more time on it for pajamas (2) allow us to understand if our thinking/data is wrong and people do in fact need ACH (3) set us up for moving to the v2 API for Stripe, which does not support it.

Story points: 1.0
Style error messages under Pajama's Design System

The proposed change is approved and is currently behind [pajamas_error_messages](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/1546/edit) feature flag.

### Problem

The validation error messages are not being styled properly under Pajamas updates in &1788.

![Screen_Shot_2020-01-20_at_11.03.00](/uploads/7d6f99136f9deb15060b5199aac59259/Screen_Shot_2020-01-20_at_11.03.00.png)

### Proposal

Wrap the current errors within a [danger alert](https://design.gitlab.com/components/alert/). 


### Next steps (if any)

- [x] Validation and approval from ~UX 
- [x] Add weight and schedule

Story points: 1.0
Subscription adjustment buttons should not be offered when the subscription is expired.

### Problem
Once a subscription expires, there is a short period (maybe 24 hours - need to check with AR), where a user can still renew and the card will try to process the payment. After that short period, if a user tries to renew using the "Resume Subscription" button or "Auto Renew" toggle, the renewal will not process. Offering this button to users after expiration is confusing.

In some cases the subscription does appear active after these actions but the user is never billed.

Additionally, there is a timeframe that when the customer reengages after "x" days post-renewal date, they become a "new" order rather than a "renewal" order. We should obtain how sales defines and align the behavior.

### Proposal

Remove all buttons beneath an expired subscription including "Resume Subscription", "Change linked group", and "Buy more CI minutes" from the subscription widget once the subscription is expired. This applies to both .com and self-managed subscriptions/licenses.

NOTE: We're only doing this in the new Pajamas (vue) interface. 

![Resume_Subscriptoin](/uploads/9282c62d6bb5c98f48b220313ccdbd15/Resume_Subscriptoin.png)

Story points: 1.0
[Deprecate Zuora SOAP] Update test helpers and factories to use Zuora REST API

### Problem
The test helpers in [zuora_test_helpers.rb](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/bcc08aba11dbdc6044635ef24bc257ac55a28aa4/spec/support/helpers/zuora_test_helpers.rb) and [stub_zuora_calls.rb](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/bcc08aba11dbdc6044635ef24bc257ac55a28aa4/spec/support/stub_zuora_calls.rb) are littered with `zuora_rest_api` feature flag logic.  Also, [Zuora object factories](https://gitlab.com/gitlab-org/customers-gitlab-com/tree/staging/spec/factories/z) create `active_zuora` objects (`Z::`).

### Proposal
We should transition to using the Zuora REST API (`IronBank`) where possible in the test helpers and factories.

- Remove the feature flag logic from the test helper files.
- Update the factories to create `Zuora::` namespaced objects, instead of `Z::` namespaced objects.

### Result
Cleaner test helpers and factories.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
[REST Update] Fix bug in auto-renew amendments

### Problem
The recent deployment of subscription amendments using Zuora REST API prompted errors related to auto-renew amendments.

https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1181887/?referrer=slack

### Proposal
Fix bug in the Zuora REST API amendments

### Result
Functional auto-renew amendments via REST API.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Adopt Unleash for rolling out Pajamas

<!-- 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
With [Pajamas conversion](https://gitlab.com/groups/gitlab-org/-/epics/1788) we will end up with a number of [feature flags](https://gitlab.com/groups/gitlab-org/-/epics/1788#feature-flags)

Enabling feature flags currently is to SSH into the box and toggle the flag from the command line.
This requires access to the staging and production server to toggle the flag and to query which flags are enabled.

Disabling a feature flag if something is wrong can also be time consuming.

### Proposal

[Unleash](https://docs.gitlab.com/ee/user/project/operations/feature_flags.html) has solves a number of these problems.

[Unleash is enabled in the Customer Portal](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/758) so adopting Unleash requires updating existing feature flags (2 as of opening this issue) to the `Unleash` prefix: https://gitlab.com/gitlab-org/customers-gitlab-com#feature-flags-unleash

### Result

Feature flags are visible in a central place: https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags

### Next steps (if any)

Document how to use Unleash in local development

Story points: 1.0
Follow-up from "Health check adjustments"

The following discussion from !865 should be addressed:

- [ ] @rdavila started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/865#note_269968174):  (+5 comments)

    > @cwiesner @jejacks0n regarding the usage of the `okcomputer` gem, I really like it, it will be less code to write and maintain for us, it has all the features that we've in our current implementation.

Story points: 1.0
Re-populate "mark as default" checkbox when editing a credit card

The following discussion from !772 should be addressed:

This came up in a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/772#note_271284795) while converting the edit payment method to Pajamas. It is related to making a payment method the default one:

    If you edit a payment method and you want to make it a default but the form contains an validation error,
    the check box will be unchecked again. I tried adding a check to set the checkbox to check, but then it
    will be disabled.

It will disabled due to not being able to remove it for the real default payment method. Which is not the case here.

Story points: 3.0
Follow-up: change admin table dates format

<!-- 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/

-->

This is a follow-up to https://gitlab.com/gitlab-org/customers-gitlab-com/issues/865.

### Problem

The admin table is too congested.


### Proposal

@timnoah [said in the main issue's MR](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/858#note_269208798):

> As this is quite a congested table to relieve some of the pressure on wrapping headers could we change the date formatting on **created at** and **updated at** to `MM DD, YYYY hh:mm` Example, **Dec 20, 2019 15:34**?

@aalakkad said: 

> I'm not sure how easy it is to do that in rails_admin, for a quick search I found [a way](https://stackoverflow.com/a/32631342) to configure the date format, but I can't be sure if it has any implications for other parts of the system.


### Result

Comfortable tables in the admin panel.

### Next steps (if any)

Validate the issue and schedule.

### How will we measure success?

Story points: 2.0
Remove annotation gem or define process by which they are regularly updated.

The following discussion from !870 should be addressed:

- [ ] @oswaldo started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/870#note_268272515):  (+5 comments)

    > My feeling at the moment is that [the annotations] will quickly become stale if we don't have someone taking care of it constantly :thinking:

Story points: 1.0
Update Zuora Sandbox creds for CI and customers.stg.gitlab.com to use an API account

### Problem
It appears that we routinely (every 6 months?) have to update the Zuora API Sandbox password which is used for CI and for customers.stg.gitlab.com.  In the past, when we've updated these creds, there is confusion around the process as well as downtime in the CI Pipeline and at customers.stg.gitlab.com.  This can cause delays in deploys while the infrastructure team updates the password in the chef-vault.

More info can be found in [the Slack thread discussion](https://gitlab.slack.com/archives/CMJ8JR0RH/p1578582393061900?thread_ts=1578566280.044100&cid=CMJ8JR0RH).
### Proposal
We should update the Zuora sandbox credentials used for CI and staging to be an "API account" so that the credentials never expire and we don't have to update them routinely.

### Result
No downtime in CI and staging as a result of expired credentials.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
500 error on staging - undefined method `find' for false:FalseClass

<!-- 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

```
I, [2020-01-09T10:45:30.627978 #19373]  INFO -- : [eba979eb-44a4-4915-9977-a84d41a10652] Completed 500 Internal Server Error in 773ms (ActiveRecord: 0.0ms)
D, [2020-01-09T10:45:30.628546 #19373] DEBUG -- : [eba979eb-44a4-4915-9977-a84d41a10652] undefined method `find' for false:FalseClass excluded from capture: Not configured to send/capture in environment 'stg'
F, [2020-01-09T10:45:30.629413 #19373] FATAL -- : [eba979eb-44a4-4915-9977-a84d41a10652]
F, [2020-01-09T10:45:30.629477 #19373] FATAL -- : [eba979eb-44a4-4915-9977-a84d41a10652] ActionView::Template::Error (undefined method `find' for false:FalseClass):
F, [2020-01-09T10:45:30.629675 #19373] FATAL -- : [eba979eb-44a4-4915-9977-a84d41a10652]     1: - starter_plan = PlansFinder.find(Plan::GITLAB_EE_STARTER_1_YEAR_PLAN)
[eba979eb-44a4-4915-9977-a84d41a10652]     2: - premium_plan = PlansFinder.find(Plan::GITLAB_EE_PREMIUM_1_YEAR_PLAN)
[eba979eb-44a4-4915-9977-a84d41a10652]     3: - ultimate_plan = PlansFinder.find(Plan::GITLAB_EE_ULTIMATE_1_YEAR_PLAN)
[fb473b97-a019-4421-a380-5e80c3418c05]     4:
F, [2020-01-09T10:46:16.707317 #19370] FATAL -- : [fb473b97-a019-4421-a380-5e80c3418c05]
F, [2020-01-09T10:46:16.707397 #19370] FATAL -- : [fb473b97-a019-4421-a380-5e80c3418c05] app/models/plans_finder.rb:47:in `find'
[fb473b97-a019-4421-a380-5e80c3418c05] app/views/plans/index.html.haml:1:in `_app_views_plans_index_html_haml___173243987165318374_65993680'
[fb473b97-a019-4421-a380-5e80c3418c05] lib/zuora_proxy.rb:16:in `perform_request'
[fb473b97-a019-4421-a380-5e80c3418c05] app/middleware/basic_health_check.rb:20:in `call'
```

### Proposal

Investigate whether it's a legitimate error and put a fix

### Result

### Next steps (if any)

### How will we measure success?

cc @fulfillment-group @mkarampalas

Story points: 0.0
Salesforce lead service errors occurring after deploys following holiday break

### Problem
Numerous errors similar to the one below have occurred since the deploys to production were fixed yesterday (1/6) following the holiday break.

```
#<Faraday::ClientError response={:status=>400, :headers=>{"date"=>"Tue, 07 Jan 2020 07:53:02 GMT", "strict-transport-security"=>"max-age=31536002; includeSubDomains", "public-key-pins-report-only"=>"pin-sha256=\"9n0izTnSRF+W4W4JTq51avSXkWhQB8duS2bxVLfzXsY=\"; pin-sha256=\"5kJvNEMw0KjrCAu7eXY5HZdvyCS13BbA0VJG1RSP91w=\"; pin-sha256=\"njN4rRG+22dNXAi+yb8e3UMypgzPUPHlv4+foULwl1g=\"; max-age=86400; includeSubDomains; report-uri=\"https://a.forcesslreports.com/hpkp-report/00D61000000JNOFm\";", "expect-ct"=>"max-age=86400, report-uri=\"https://a.forcesslreports.com/Expect-CT-report/00D61000000JNOFm\"", "x-robots-tag"=>"none", "cache-control"=>"no-cache,must-revalidate,max-age=0,no-store,private", "set-cookie"=>"BrowserId=utYxfzEiEeqcR_fg1u8E2w;Path=/;Domain=.salesforce.com;Expires=Sat, 07-Mar-2020 07:53:02 GMT;Max-Age=5184000", "expires"=>"Thu, 01 Jan 1970 00:00:00 GMT", "sforce-limit-info"=>"api-usage=346137/965600", "content-type"=>"application/json;charset=UTF-8", "transfer-encoding"=>"chunked", "connection"=>"close"}, :body=>[{"message"=>"Newsletter: value not of required type: ", "errorCode"=>"INVALID_TYPE_ON_FIELD_IN_RECORD", "fields"=>["newsletterSegment__c"]}]}>
```

There are plenty of similar reports in Sentry:
https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1158625
https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1159399/?query=is:unresolved
https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1159395/?query=is:unresolved
https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1159394/?query=is:unresolved

### Proposal
Investigate and implement a fix.

### Result
A functional salesforce integration.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Add backtrace to gitlab logger when error type is Error

### Problem

Currently when a log_error is called with the error object the Raven is called with `capture_exception` and the error is send as an inspect of the error object. 

### Proposal

When calling [Raven.capture_exception](https://github.com/getsentry/raven-ruby/blob/ad440b952de0f62b62c42433882887c2cb678caf/lib/raven/event.rb#L181), the method checks itself whether the parameter is a exception or a string and will add backtrace if exists.

 Call `message = message.is_a?(String) ? message : message.inspect` after `Raven.capture_exception(message, extra: extra)` 

### Result

This will help in backtrace all the custom exceptions raised by the application. 

@jameslopez

Story points: 1.0
Refactor the Subscription#trueup_info method to query within date range rather than filter in Ruby

The following discussion from !866 should be addressed:

- [ ] @asubramanian1 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/866#note_267778598):  (+1 comment)

    > I understand this is an existing logic, however is there a preference to use the ruby method `cover?` here over adding a clause while querying? 
    > 
    > Related to what's done for [REST](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/staging/lib/zuora/invoice.rb#L10) and [SOAP](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/staging/config/initializers/zuora.rb#L85) previously for similar instances.
    > 
    > In case you agree, am okay with creating a follow-up issue given it's a refactor.

Story points: 1.0
[Deprecate Zuora SOAP] Remove SOAP code from the Subscription model

### Problem
Once the Zuora REST update is complete and the SOAP code is no longer needed, we will have plenty of unused legacy code that should be removed.

### 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 `Subscription` model which was added in #983.

### Result
A cleaner code base with less feature flags.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
[Deprecate Zuora SOAP] Remove SOAP code from the PlansFinder

### Problem
Once the Zuora REST update is complete and the SOAP code is no longer needed, we will have plenty of unused legacy code that should be removed.

### 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 `PlansFinder` which was added in #982.

Other things to remove:
- [Rescuing the `Savon::SOAP::Fault` error](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/2aa0226d267b655f87f9c30918d42917bc67348c/app/models/plans_finder.rb#L28)
- [Rescuing the DB errors in `Feature#enabled?`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/2aa0226d267b655f87f9c30918d42917bc67348c/lib/feature.rb#L53)

### Result
A cleaner code base with less feature flags.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
[Deprecate Zuora SOAP] Remove SOAP code from the subscriptions_controller

### Problem
Once the Zuora REST update is complete and the SOAP code is no longer needed, we will have plenty of unused legacy code that should be removed.

### 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 `SubscriptionsController` which was added in #981.

### Result
A cleaner code base with less feature flags.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
[Deprecate Zuora SOAP] Remove SOAP code from mailers

### Problem
Once the Zuora REST update is complete and the SOAP code is no longer needed, we will have plenty of unused legacy code that should be removed.

### 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 Mailers which was added in #922.

### Result
A cleaner code base with less feature flags.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
[Deprecate Zuora SOAP] Remove SOAP code related to invoice files in Payment History page

### Problem
Once the Zuora REST update is complete and the SOAP code is no longer needed, we will have plenty of unused legacy code that should be removed.

### 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 invoice files in the Payment History page, which was added in #921.

### Result
A cleaner code base with less feature flags.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
[Deprecate Zuora SOAP] Remove SOAP code related to updating a Zuora contact

### Problem

Once the Zuora REST update is complete and the SOAP code is no longer needed, we will have plenty of unused legacy code that should be removed.

### 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 updating a Zuora contact which was added in !813.

### Result

A cleaner code base with less feature flags.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
[Deprecate Zuora SOAP] Remove SOAP code related to creating new subscriptions

### Problem

Once the Zuora REST update is complete and the SOAP code is no longer needed, we will have plenty of unused legacy code that should be removed.

### 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 creating new subscriptions which was added in #833.

### Result

A cleaner code base with less feature flags.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Unify colors between @gitlab/ui and the project

<!-- 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

There are conflicting colors between our project and the pajamas.

In our `variables.scss` we have:

```scss
$gray-400: #444;
$gray-500: #a1a1a2;
$gray-600: #d2d2d2;
$gray-700: #fafafa;
$gray-800: #dfdfdf;
$gray-900: #707070;
```

In pajamas `variables.scss`:

```scss
$gray-400: #bababa;
$gray-500: #a7a7a7;
$gray-600: #919191;
$gray-700: #707070;
$gray-800: #4f4f4f;
$gray-900: #2e2e2e;
```

### Proposal

Unify the colors code in our project so we will follow the same color convention as pajamas.

Which will need careful changing in our stylesheets that use any of the `$gray-*` variables.

### Result

### Next steps (if any)

- [ ] Validate proposal.
- [ ] Schedule the issue.

### How will we measure success?

Story points: 1.0
[REST Update] Update the Subscription model to use the REST API

### Problem

The following are two references to the Zuora SOAP API that should be updated to use the REST API (with feature flags).

```
app/models/subscription.rb
  173,43:                    product_rate_plan_ids: Z::RatePlan.where(amendment_id: amendment_id).map(&:product_rate_plan_id) }
  185,19:       amendment = Z::Amendment.find_with_array(:id, amendment_ids).order(:created_date, :desc).detect do |a|
```

### Proposal

Update these references to optionally use the REST API based on the feature flag `zuora_rest_api`.

### Result

The eventual removal of dependence on the obsolete Zuora SOAP API.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
[REST Update] Update the PlansFinder to use the REST API

### Problem

The following are two references to the Zuora SOAP API that should be updated to use the REST API (with feature flags).

```
app/models/plans_finder.rb
  86,31:       @product_rate_plans ||= Z::ProductRatePlan.find_with_array(:id, PRELOAD_PLAN_IDS)
  90,38:       @product_rate_plan_charges ||= Z::ProductRatePlanCharge.find_with_array(
  96,43:       @product_rate_plan_charge_tiers ||= Z::ProductRatePlanChargeTier.find_with_array(
```

### Proposal

Update these references to optionally use the REST API based on the feature flag `zuora_rest_api`.

### Result

The eventual removal of dependence on the obsolete Zuora SOAP API.

### Next steps (if any)

### How will we measure success?

Story points: 1.0