giseldo/neodataset huggingface dataset:
Refactor can_activate_cloud_license logic

### Problem
The current activation code logic includes a check for eligibility: `can_activate_cloud_license?`

This eligibility is currently dependent on the other Super Sonics fields being populated. This is causing problems and is not a relevant dependency.

### Proposal
Remove this SS dependency to ease the creation of activation codes.

In the check for `can_activate_cloud_license?` ([code](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/fe7feb2659aff9cd2bf60e998e91c042462a29c8/app/models/subscription.rb#L461)), remove:

* `ContractSeatReconciliation__c` is not `null`
* `ContractAutoRenew__c` is not `null`
* `ContractOperationalMetrics__c` is not `null`
* The method `Subscription#can_activate_cloud_license?` would only check for `self_service?` which can be used directly instead


### Result
In tandem with https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4688, this will remove the dependency of the other SS fields being populated on the creation of a cloud license activation code.

### 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 -->

Based on the description:

> ... Super Sonics fields being populated. **This is causing problems** and is not a relevant dependency.

These problems are likely to have risen from a lack of test coverage.  Let's isolate and determine where the test gap is and fill it.

Story points: 1.0
Clean up SaaS Provisioning Email

<!-- 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 noticed while recording an [updated SaaS provisioning flow walkthrough](https://www.youtube.com/watch?v=rg8liZIQ2Mo) ([issue](https://gitlab.com/gitlab-org/gitlab/-/issues/370481)) that the SaaS provisioning email is not the greatest UX. Let's try to clean this one up however possible.

This is for the html email for a GL.com purchase from Salesforce `CustomerMailer.gl_com_purchase_from_sf` - found here: https://gitlab.com/-/ide/project/gitlab-org/customers-gitlab-com/tree/remove_quotes_in_gl_com_purchase_from_sf_html_email/-/app/views/customer_mailer/gl_com_purchase_from_sf.html.haml/

**Current View:**

![image](/uploads/7b6f1dd0a65fccc58dfb7a6809876b3a/image.png)

### Proposal
![SaaS_Provisioning](/uploads/af59f47921bcde4060edb1261e07a839/SaaS_Provisioning.png)

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->


#### Figma Design
[Figma File](https://www.figma.com/file/RwDEORCySqiDhagP7OJSde/Clean-up-SaaS-Privisioning-Email?node-id=0%3A1)

First iteration design and design feedback can be found here - https://gitlab.com/gitlab-org/gitlab/-/issues/370481/designs/SaaS_Provisioning.png

### Links
| Linked Email Text | URL |
| ------ | ------ |
| login | https://gitlab.com/users/sign_in |
| register | https://gitlab.com/users/sign_up |
| Create a new group | https://docs.gitlab.com/ee/user/group/manage.html#create-a-group |
| Owner | https://docs.gitlab.com/ee/user/permissions.html#group-members-permissions |
| Contact our support team | https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=360000803379 |
| Link your GitLab user account to your Customers Portal account | https://docs.gitlab.com/ee/subscriptions/index.html#change-the-linked-account |
| Link your subscription to your namespace | https://docs.gitlab.com/ee/subscriptions/index.html#change-the-linked-namespace |
| view your GitLab SaaS subscription | https://docs.gitlab.com/ee/subscriptions/gitlab_com/#view-your-gitlab-saas-subscription |
| GitLab Support | https://about.gitlab.com/support/ |
| footer: logo | https://about.gitlab.com/ |
| footer: Support | https://about.gitlab.com/support/ |
| footer: Customers Portal | https://customers.gitlab.com/customers/sign_in |
| footer: Blog | https://about.gitlab.com/blog/ |
| footer: Contact Sales | https://about.gitlab.com/sales/ |

## Result
* Email is clearer, more concise, and more visually appealing with obvious sections

Story points: 2.0
Add validations on the use of feature category (Follow-up from "Link the "feature_category" class attribute to the Prometheus collector")

The following discussion from !5241 should be addressed:

- [ ] @reprazent started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5241#note_1067118408):  (+3 comments)

    > Should we still populate the labels for these controllers if they can receive requests? We can have the `endpoint_id` built and use the fallback feature category.
    > 
    > Only if they'd never receive requests, we can exclude them. Is that the case here?

Story points: 1.0
Improve license text on subscription page

<!-- 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

Currently, some of the text displayed on the Subscription Admin Page and Admin Overview page within a self-managed subscription is confusing to customers.
* The text "Renews: in X days" is confusing/alarming to customers:
  * Who are not on auto-renew - this is not accurate as they actually will lose access
  * Who have already purchased a renewal subscription that is an upgrade from their current - this is not accurate
* The text "Valid From" isn't very clear - saying something simpler may be clearer to customers
* "Expires on" is harsh, and can imply the end of a subscription even if a customer has already renewed

### Proposal

#### Changes on the Admin > Subscription page

Update the following text under `Subscription details` to reduce customer confusion:
1. Change `Renews` to `End date`
1. Change the End date format from an relative date (eg, `in 11 days`) to an absolute date (eg, `2022-08-06`)
1. Change `Started` to `Start date`
1. Change `Last Sync` to `Last sync` (sentence case)
1. Update the order to be:
     - Start date
     - End date
     - Last sync


Update the following text under `Subscription History`:
1. Change "Valid From" to "Start date"
2. Change "Expires On" to "End date"
3. Change "Activated on" to "Activation date"

![image](/uploads/7f386353470ca0c5c7b804dee3c389ab/image.png)


#### Changes on the Admin > Overview page

Update the following text under `License overview` to reduce customer confusion:
1. Change `Expires` to `End date`

![image](/uploads/c0a66ce0740f91ec6a0b5105cebc7341/image.png)

### Result
Customer is more clearly able to understand the current state of their subscription.

Story points: 1.0
Introduce Manager Service for amendments

<!-- 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

Introduce `AmendmentManagerService` that will serve as an entry point for amendment workflow.

The purpose of this service is to:
  - determine the order action types for the request (based on `params`)
  - verify feature availability for the determined order action types
  - trigger order manager service if feature availability passed

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Create `ActionTypeGenerator` that determines possible order action types. Create `AmendmentManagerService` that does the following:

  - invokes `ActionTypeGenerator` to get possible order action types. If no order actions were found, return an error response so we can fallback to existing amendment workflow.
  - run feature availability on the order action types
  - trigger order manager service if feature availability returns `true`. If `false`, return an error response so we can fallback to existing amendment workflow.



### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Integrate UpdateProduct order action with OrderManagerService

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5162 introduced an order action service for `UpdateProduct`. This issue pertains with integrating it in the amendment workflow.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Product update is being handled in [AmendSubscriptionService](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/services/amend_subscription_service.rb).

For the options that are needed in `UpdateProduct` we can either pass the options directly from `AmendSubscriptionService` or pass params to a `FilterService` which returns the required options.

note: `AmendSubscriptionService` handles multiple amendments in a single call, we need to check if we can replace individual amendment actions with the new order service or do we need to wait for all actions to be implemented before we can integrate the new order service.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Follow-up: remove "optional" from cancellation survey checkboxes section

<!-- 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

<!-- Describe the problem in terms which a user may understand. Avoid providing solutions in this section -->

As part of the changes made in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4035, we added to the header that the selection of cancellation reason is optional. See before/after here: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4035#note_971075680

This then lead to a drop in responses as outlined in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4035#note_1052667342

## Proposal

<!-- Describe the proposed solution the problem -->

We'd like to remove the `(optional)` from the top header, so instead of
`Could you tell us a bit more about your cancellation? (optional)`

It should read 
`Could you tell us a bit more about your cancellation?`

Note that the actual selection should continue to be optional, just like it has always been, and we shouldn't block the form submission on requiring them to select an option. 

## Next steps (if any)

<!-- If there are follow-up issues required, describe them here -->

## How will we measure success?

Increase in submissions.

Story points: 1.0
Revise cancellation modal to include a dropdown vs multiselect

<!-- 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

Currently, the cancellation modal is very busy – primarily due to the 'cancellation reason' options. This increases cognitive load for the user. Given that there is also an [issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3981) to add content to this modal regarding overages, it may be wise to look at a simpler design for this modal.

##### Current Experience

 ![image](/uploads/fee9b83ffe08434e063ae631dc556761/image.png) 

## Proposal
![Update_subscription_cancellation_modal](/uploads/e1f7d7c3bafabd61cd41853beab9a267/Update_subscription_cancellation_modal.png)

Replace the multi select options with a dropdown, which will include all the current options. 

## Design
[Figma File](https://www.figma.com/file/WfIcP3jg6nkBT0GCqkZvTE/Cancellation-%E2%80%93%C2%A0Info-on-overages?node-id=0%3A1)

Story points: 2.0
Add script for generating feature categories

<!-- 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

Port the [`update-feature-categories`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/scripts/update-feature-categories) script and generate `config/feature_categories.yml` file.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Expired subscription has a Cancel subscription button

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label in relevant trackers:

- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug
- https://gitlab.com/gitlab-org/customers-gitlab-com/issues?label_name%5B%5D=bug

and verify the issue you're about to submit isn't a duplicate.

Do not include confidential information!
--->

# Bug

## Summary

The customer subscription failed to auto renew because of payment failure. When the subscription expires, there's no renew button but the `Cancel Subscription` button. 

## Steps to reproduce

(How one can reproduce the issue - this is very important)

## What is the current *bug* behavior?

(What actually happens)

## What is the expected *correct* behavior?

(What you should see instead)

## Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's tough to read otherwise.)

![image](/uploads/1970be9b319f3979ae09633a0e00f14e/image.png)

## Workarounds

(Ways to get around the issue)

## Reported examples

1. https://gitlab.zendesk.com/agent/tickets/314929
1.
1.

<!---
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
Activate cloud license during installation

### Problem

Customers were able to add their [license file during installation](https://docs.gitlab.com/ee/user/admin_area/license_file.html#add-your-license-file-during-installation) of their GitLab instance when using a legacy license. With Cloud License this is no longer possible. 

Please note more details in this issue: https://gitlab.com/gitlab-org/gitlab/-/issues/383878

### Workaround

Request an [offline cloud license](https://about.gitlab.com/pricing/licensing-faq/cloud-licensing/#offline-cloud-licensing), which can be applied during installation.

### Proposal

Add the ability to add activation code during the installation of a GitLab instance, similar to what was possible for legacy licenses: https://docs.gitlab.com/ee/user/admin_area/license_file.html#add-your-license-file-during-installation.

### Reported Examples
1. https://gitlab.zendesk.com/agent/tickets/315115
1. https://gitlab.zendesk.com/agent/tickets/343826
2. https://gitlab.zendesk.com/agent/tickets/365130

Story points: 3.0
Use OrderManagerService to renew subscription

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4326 implemented Order action `Zuora::Orders::Actions:: RenewSubscription` that constructs the request body to renew a subscription.

The next step is to use this order action in `OrderManagerService` to renew a subscription.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

:warning: Depends on [AmendmentManagerService](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5254) to be complete.

- Use `ActionTypesGenerator` to determine if a request pertains to renewing a subscription: see separate issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4723
- Integrate `RenewSubscription` order action with OrderManagerService: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5290

### Result

When renewing a subscription, there are other order actions involved: Adding a Product, Removing a product, Updating a product.

Consequently, the renewal workflow will not be e2e complete with this issue. However, we can use it to test a subscription is getting renewed without any seat / product changes.

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Follow-up from "SFDC: during opportunity creation, create account if absent"

The following discussion from !5186 should be addressed:

- [ ] @a_luna started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5186#note_1051504289):  (+2 comments)

    > **thought (non-blocking):** The comment here is good but since `CreateSalesforceAccountService` basically does a `find_or_create`, maybe it would be better to clarify that in the service name? Renaming it to something like  `FindOrCreateSalesforceAccountService` would be longer but self-explanatory. 
    > 
    > I see this service has been like this for a while so definitely something that could be handled in a follow up!

Story points: 1.0
Investigate "Update GitLab Plan" function / mechanizer incident

The [update gitlab plan function](https://gitlab.com/gitlab-com/support/toolbox/console-training-wheels/-/blob/master/lib/support_team.rb#L86) seems to be the root cause of https://gitlab.com/gitlab-com/gl-infra/production/-/issues/7555

We need to investigate why.

From `@jameslopez`:

> its process was using up to half the total memory and killing it brought the system back up (as well as reducing CPU load). there could be many causes to this, from a race condition to a memory leak somwhere

Story points: 5.0
Remove Customer dependency from Subscription model

### Problem

In CustomersDot, a `Subscription` model exists as a wrapper around a `Zuora::Subscription` object.  This wrapper is meant to contain business logic specific to CustomersDot.  The `Subscription` class has an initialization dependency on having a `Customer` record ([see code](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/99ecaa74572bcf1542b5ab9fadba3f410b402b18/app/models/subscription.rb#L93)).  This dependency does not seem to be necessary and only adds to the complexity in our system.  

In most places, the `Customer` record is used simply as a way to determine the `zuora_account_id` for the subscription, but we should be getting this directly from the `Zuora::Subscription` instead.  In other places, it is used to determine who should receive provisioning emails, but this can also be determined from using Zuora (the Sold To contact of the Zuora Account).

### Proposal

Identify and update all places where the `customer` is referenced from the `Subscription` object, and eventually remove the dependency altogether.  We can start with the easy references where customer is used to get the `zuora_account_id`.

### Result

A much cleaner and understandable `Subscription` class.  This will also enable us to rely more on Zuora data and less on the customer data in CDot which helps towards the initiative in https://gitlab.com/groups/gitlab-org/-/epics/8331.

Story points: 8.0