giseldo/neodataset huggingface dataset:
[Portal Pajamas] Upgrade Bootstrap to version 4

<!-- 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 want to consume `gitlab-ui` components https://gitlab.com/gitlab-org/customers-gitlab-com/issues/729

To do this we need to be on bootstrap v4.
### Proposal
Upgrade to bootstrap v4.

Ensure any UI change is intentional.

Migration guide: https://getbootstrap.com/docs/4.0/migration
### Result
We're ready for `gitlab-ui`

Story points: 5.0
Move our JS to webpack

<!-- 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/

-->
Background: https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/521#note_229943169
### Problem
We overreached when merging !470 and a bug snuck in; which was fixed in !514
The diff is too large to review with fresh eyes, so let's break it up.

### Proposal
Make a clear separation of migrating to webpack.
Since our dependencies are loaded and attached via global scope we can do a gradual migration.

1. Move global dependencies to webpack (https://gitlab.com/gitlab-org/customers-gitlab-com/issues/751)
2. Move our JS (`app/assets/javascripts`) to webpack (that's this ticket)

Story points: 5.0
Move global JS dependencies to Webpack

<!-- 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/

-->
Background: https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/521#note_229943169
### Problem
We overreached when merging !470 and a bug snuck in; which was fixed in !514
The diff is too large to review with fresh eyes, so let's break it up.

### Proposal
Make a clear separation of migrating to webpack.
Since our dependencies are loaded and attached via global scope we can do a gradual migration.

1. Move global dependencies to webpack (that's this ticket)
2. Move our JS (`app/assets/javascripts`) to webpack (see https://gitlab.com/gitlab-org/customers-gitlab-com/issues/752)

Dependencies (double check that this is a correct list when implementing)
* Query and its plugins
* Bootstrap
* Zuora's script
* Accounting script
* snowplow? /cc @gitlab-org/growth
* URI.js
* chosen
* `eu_country_codes`

Story points: 3.0
LicenseNotificationService should accept a subscription object only

The following discussion from !506 should be addressed:

- [ ] @asubramanian1 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/506#note_229525163): 

    > (Not to fix in this MR) - but it would be nice if the method accepts either `subscription_id` or `subscription_object`


Story points: 1.0
Gracefully handle errors in CreateOrderService

The following discussion from !506 should be addressed:

- [ ] @asubramanian1 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/506#note_229438928):  (+1 comment)

    > Wdyt about rescuing the operation, and returning `{ success: false }`
    > 
    > https://gitlab.com/gitlab-org/customers-gitlab-com/blob/24d53e03a63059232dcdc6931e25d21b3fe36841/app/services/create_order_service.rb#L27 and others could raise exception

Story points: 2.0
[REST Update] Update Zuora base url and authentication 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
The REST API base url for Zuora we have in code: https://gitlab.com/gitlab-org/customers-gitlab-com/blob/staging/lib/zuora/rest_client.rb#L7 is different than what's mentioned in Zuora documentation: https://www.zuora.com/developer/api-reference/#section/Introduction/Access-to-the-API. It's probably an old url and Zuora has deprecated it by now (could not find reference docs).

The old url probably still works (used in Receipts and Digital Signature), but would be good to update to the latest ones.

Also, Zuora recommendeds to use API token as a way to authenticate. Currently, we use the legacy way of `apiAccessKeyId` and `apiSecretAccessKey` to authenticate: https://www.zuora.com/developer/api-reference/#section/Authentication/Other-Supported-Authentication-Schemes

### Proposal
* [ ]  Update base url to conform with Zuora documentation
* [ ]  Change authentication method to use tokens

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Follow up: extract inline JS to erb file

<!-- 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/merge_requests/521#note_227722085

### Problem

We're having inline JS in layout files to pass data from Rails to JS, we can unify those files and include it instead.

### Proposal

Extract inline JS to erb file and include it instead.
Use https://github.com/rails/webpacker#erb for reference.

### Result

Remove code redundancy and all JS that are not handled by webpacker.

### Next steps (if any)

### How will we measure success?

Story points: 4.0
Add feature flag for processing orders callouts

### Background

To get [Zuora Orders Harmonization](https://gitlab.com/groups/gitlab-org/-/epics/6641) working in CustomersDot, there are many things to still sort out.  We've found that with Orders Harmonization enabled in Zuora, when using the Amend API to modify subscriptions, CustomersDot can receive multiple callouts to the `subscription_update` endpoint.  This is because with Order Action Processed callouts configured alongside the Amendment Processed callouts, both will be triggered in Zuora.  When the Order feature is used, only the Order Action callout will be triggered.

It seems likely that we will need a feature flag for Orders Harmonization.  This will serve as an indicator to know which callouts to process.

### Proposal

Introduce a feature flag, `orders_harmonization`, which will server as an indication of which callouts to process.  With the flag enabled, CustomersDot should process Orders-related callouts.  If disabled, CustomersDot should process the existing amendment-related callouts.

To distinguish Orders-related callouts from amendments-related callouts, we could check the callout body params for `order_id`.  We're not exactly sure at this moment what type of callout will be used for orders (see [this thread](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/intake/-/issues/322#note_666782612) for more info), but it seems like whether we go with order processed or order action processed, either one should contain an `order_id`.

### Result

Feature flag created: https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/104/edit

Story points: 1.0
Remove amendment from Product object

## Background

When using the Amend API to make changes to a subscription, the Subscription Rate Plan ends up with a reference to the `amendment_id` responsible for the change. As part of the [Orders Harmonization](https://gitlab.com/groups/gitlab-org/-/epics/6641) testing, we noticed when using Orders to make changes to a subscription, there is no `amendment_id` on the Subscription Rate Plan (interestingly there is an `amendment_type`).

CustomersDot uses this reference to the `amendment_id` in order to build a `Product` object ([ref](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/ac33b9df3ddfd21f27eaad5e452d86394ecb7384/app/models/product.rb#L22)) for the subscription (think of this as an object representing the products attached to the subscription). 

As far as we can tell, the amendment on the Product is used only to determine [the ](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/ac33b9df3ddfd21f27eaad5e452d86394ecb7384/app/models/product.rb#L52)`created_at` datetime of the Product. CustomersDot is using the `created_date` of the amendment as the Product's `created_at` date. It's not exactly clear why this is using the amendment, but was introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/333 over 2 years ago. Perhaps this information could be pulled from the Subscription Rate Plan, Charge or Tier, and eliminate this dependency on the amendment.

## Purpose

Investigate if `amendment` can be removed from [the `Product` model](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/ac33b9df3ddfd21f27eaad5e452d86394ecb7384/app/models/product.rb#L22).  It appears to only be used for [the `created_at` method](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/ac33b9df3ddfd21f27eaad5e452d86394ecb7384/app/models/product.rb#L52) (but we should confirm that).  If we use other object like the Subscription Rate Plan, Charge or Tier to get a "created" timestamp of the product, we would be able to remove amendment.

We also noticed that the [amendment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/937b0ca6dd146c43fb21a5d8bff356824e052bd9/app/models/subscription.rb#L72) in the subscription object appears to be only used for product initialization. We should determine if it can be removed from Subscription as well.

Story points: 2.0
Add Danger reminder for updating DB structure diagrams

# Proposal

As mentioned in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3547#note_667582820, [the `database/Dangerfile`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/9c670a912f16fa2877c4ed8d96c572cb525f75ab/danger/database/Dangerfile) could be updated to include a reminder about how/where to update the [db structure diagrams on the Fulfillment architecture page](https://about.gitlab.com/handbook/engineering/development/fulfillment/architecture/#database-structure-of-customersdot-and-licensedot).

Story points: 1.0
[Documentation] CustomersDot <> Zuora Object Mapping

### Problem

We need a way to understand how Zuora objects are mapped in CustomersDot.  This helps solve several business and technical challenges.  For one, this helps when analyzing impact of a change.  It helps in describing scope of a required change.  It can also help with communicating the state of a subscription resulting from an order/account update.

### Proposal

Create information oriented documentation that describes and maps Zuora object fields to fields in CustomersDot.  At the very least, the documentation includes:

- list of fields in CustomersDot and the corresponding field it maps to in Zuora
- each field is fully qualified and specifies the source, table name and field name (ie: Source, TABLE_NAME.FIELD_NAME )
- each field describes when they are initialized, and possibly subsequent updates, if appropriate
- each field describes initial value, if appropriate

Story points: 2.0
Error transferring CI minutes between namespaces

https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2780568/?referrer=gitlab_plugin

```
Stacktrace (most recent call first):

  lib/gitlab/logger_helpers.rb:24:in `public_send'
    Gitlab::Logger.public_send(log_level, object, options) # rubocop:disable GitlabSecurity/PublicSend
  lib/gitlab/logger_helpers.rb:24:in `log'
    Gitlab::Logger.public_send(log_level, object, options) # rubocop:disable GitlabSecurity/PublicSend
  lib/gitlab/logger_helpers.rb:13:in `log_error'
    log(:error, error, extra: extra)
  app/services/gitlab/hosted_plans/purchased_add_ons/transfer_ci_minutes_service.rb:23:in `rescue in execute'
    log_error(
  app/services/gitlab/hosted_plans/purchased_add_ons/transfer_ci_minutes_service.rb:17:in `execute'
    def execute
  app/services/gitlab/namespaces/update_plan_info_service.rb:120:in `update_gitlab_ci_minutes'
    ).execute
  app/services/gitlab/namespaces/update_plan_info_service.rb:77:in `update_new_namespace'
    update_gitlab_ci_minutes
  app/services/gitlab/namespaces/update_plan_info_service.rb:38:in `execute'
    update_new_namespace
  app/workers/zuora_callout/base_worker.rb:73:in `sync_gitlab_com_subscription'
    Gitlab::Namespaces::UpdatePlanInfoService.new(order, force_sync: true).execute
  app/workers/zuora_callback_worker.rb:24:in `perform'
    sync_gitlab_com_subscription(result[:order])
...
(31 additional frame(s) were not displayed)

Error transferring CI minutes between namespaces
```

Story points: 2.0
Revert quick fix of Zuora cloud license enabled flag

# Summary of problem to solve

A [quick fix](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3706) was added to fix issues where future subscriptions are not cloud license enabled.

This potentially can have a [rare edge case](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3706#note_652209766), so we should remove this fix one month after it is deployed.

## Proposal
Revert the logic in seat link to enable all future subscriptions.
___

Story points: 1.0
Update activated_at when activate request received for a previously activated instance

### Problem

As discussed in [this discussion thread](https://gitlab.com/gitlab-org/gitlab/-/issues/337531#note_661936602), an instance could fluctuate between the type of license used for their subscription.  They could start with a license file, then use a cloud license, back to a license file, and so on.  When a customer activates an instance for the first time, [the `activated_at` timestamp is set to the current datetime](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/e32106e55ef97492032ef0e8789119f637ed3272/app/services/cloud_activations/activate_service.rb#L61).  However, if the instance had previously been activated (IOW. a `SelfManagedInstanceActivation` already exists for the `activation_code` and `instance_identifier`, the `activated_at` isn't updated but it probably should be since the instance is activating again.

### Proposal

In [the `ActivateService`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/e32106e55ef97492032ef0e8789119f637ed3272/app/services/cloud_activations/activate_service.rb#L19), update the `activated_at` timestamp to the current time if the `self_managed_instance_activation` record already exists.  Also, make sure the new license generated after the `activated_at` is updated contains this change so that when synced to the instance the "Activated On" reflects the current time.

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

Adding this new logic to the activation service, to update the timestamp, a simple test should be added to ensure that this timestamp is updated to the appropriate time.  It is not enough to validate that the `activated_at` column has changed, but we must also validate the value.

Story points: 2.0
Replace Sentry.captureMessage with Sentry.captureException

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

For some reason we use `Sentry.captureMessage` for capturing exceptions and that leads to several problems:

- Unhelpful messages in out status channel in Slack. See the image below.
- `captureMessage` automatically assigns the `info` level to the message which breaks the error statistic because `captureException` sets the level to `fatal`. 

![image](/uploads/84f4af18c70d2af8791d8411433cc81f/image.png)

### Proposal

Replace all occurrences of `Sentry.captureMessage` with `Sentry.captureException` in places where we capture exceptions.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Remove obsolete trial code

## Proposal

Let's investigate whether the `/trials/new` action and its related views can be removed.  If they aren't used anymore, removing all this related code should simplify the trials code in CustomersDot, which is pretty complex at the moment.

### Follow-up

The following discussion from !3743 should be addressed:

- [ ] @jagood started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3743#note_659686621):  (+2 comments)

    > I'm not sure what this function is for.  I only see it used here:  https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e65123726c8ffb93bad38783f00ecdb2bf467b73/app/views/trials/_simple_gitlab_com_trial_form.html.haml#L16
    > 
    > Just guessing from the heading of that file, "Free Trial of GitLab.com Gold", maybe this is all unused code at this point?

We should also look at removing [`app/views/trials/_gitlab_com_trial_form.html.haml`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/2642d79401b3ecc422f71c047be30b5aff249c82/app/views/trials/_gitlab_com_trial_form.html.haml) as well as it also refers to a Gold Trial.

This should also take care of the work mentioned in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2782 related to removing these views:

* `app/views/trials/new.html.haml` 
* `app/views/trials/_simple_gitlab_com_trial_form.html.haml`

Story points: 2.0
[FE] Cloud Licensing - Workflow for Expired Cloud License

## Summary

After a license expires, the GitLab instance becomes blocked and git features like pushes are blocked. Here's a link to the docs on this: https://docs.gitlab.com/ee/user/admin_area/license.html#what-happens-when-your-license-expires. When a customer is using a license file they will renew their subscription and upload a new license file to reinstate the features or remove the license file. This will be the same behaviour for cloud licenses, but there is currently no way for a customer to remove a cloud license from their self-managed instance. This issue is to design/investigate the removal of a cloud license. [Original discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3215#note_595998053).

## Proposal

- Add a remove license button to the Admin > Subscription page for cloud licenses
- Make a request to [`LicensesController#destroy`](https://gitlab.com/gitlab-org/gitlab/blob/a90ec139423285cd8046a6373603c4b79d85e46d/ee/app/controllers/admin/licenses_controller.rb#L37) (`DELETE /admin/license`)

## Backend

Issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3525

Story points: 2.0
[BE] Cloud Licensing - Workflow for Expired Cloud License

## Summary

After a license expires, the GitLab instance becomes blocked and git features like pushes are blocked. Here's a link to the docs on this: https://docs.gitlab.com/ee/user/admin_area/license.html#what-happens-when-your-license-expires. When a customer is using a license file they will renew their subscription and upload a new license file to reinstate the features or remove the license file. This will be the same behaviour for cloud licenses, but there is currently no way for a customer to remove a cloud license from their self-managed instance. This issue is to design/investigate the removal of a cloud license. [Original discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3215#note_595998053).

## Proposal

- Add a remove license button to the Admin > Subscription page for cloud licenses
- Follow the same removal flow as legacy licenses

We should be able to reuse the same endpoint for deleting legacy licenses, [`LicensesController#destroy`](https://gitlab.com/gitlab-org/gitlab/blob/a90ec139423285cd8046a6373603c4b79d85e46d/ee/app/controllers/admin/licenses_controller.rb#L37).  We'll need to update [the `Licenses::DestroyService`](https://gitlab.com/gitlab-org/gitlab/blob/d926e54cc88ad2cba71a3579e033e10954066430/ee/app/services/licenses/destroy_service.rb#L13) to allow cloud licenses to be destroyed.

Story points: 2.0
New Trials Report as Free Plan in CustomersDot Backend

### Problem

A trial plan using one of the new `ultimate_trial` plans appears as a `free` plan in the CustomersDot admin backend.

![Free](/uploads/673feef0ba96a4c4a3da42d913182020/Free.png)

Attempting to update the plan expiration date via the UI results in a 500 error:

![Screen_Shot_2021-08-24_at_2.08.08_PM](/uploads/c8f0ebb54126df76e2c01b557eca00e2/Screen_Shot_2021-08-24_at_2.08.08_PM.png)

And then the plan no longer has any expiration date in the CustomersDot backend:

![FreeExpirationMissing](/uploads/03b98525bb75609def93e705e3e19861/FreeExpirationMissing.png)

### Proposal

The dropdown options need the new `ultimate_trial` and `premium_trial` plans.

Story points: 1.0