Remove cloud compatible check and add GitLab EE check

## Background
Currently, cloud license activation codes are generated only when a customer is "eligible". Eligibility is systematically determined based on the status "Super Sonics" fields:

* An activation code (`cloud activation`) will be created for a SM plan [here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/8baa35bbd603bf60a75a6981da4f1fbb70abe934/app/workers/zuora_callback_worker.rb#L21) if the following conditions are fulfilled (see [this method](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/fe7feb2659aff9cd2bf60e998e91c042462a29c8/app/models/subscription.rb#L401)):
   * A cloud license can be activated ([code](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/fe7feb2659aff9cd2bf60e998e91c042462a29c8/app/models/subscription.rb#L461)) which means one of the following condition should be true:
     * the subscription was self serviced (subscription bought via CustomersDot)
     * `ContractSeatReconciliation__c` is not `null`
     * `ContractAutoRenew__c` is not `null`
     * `ContractOperationalMetrics__c` is not `null`

   * The subscription is cloud compatible ([code](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/d1f1aac64a4b6cb99bbf47838d1fde5116b6468b/lib/zuora/subscription.rb#L47)) which means `TurnOnSeatReconciliation__c` is present.
If the above is met, the customer will receive either the unified mailer or the activation code mailer, and also have the option to copy the activation code from the subscription in CustomersDot. If not, we are assuming the customer is on the old terms (purchase completed prior to 2022-08-01), and not creating or providing an activation code.

## Proposal
Remove the dependency on the Super Sonics fields in order to generate a cloud license. Instead, generate an activation code for all customers where `TurnOnCloudLicensing` is not = `No`.

Specifically, remove the following conditions:

* Remove check for subscription is cloud compatible ([code](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/d1f1aac64a4b6cb99bbf47838d1fde5116b6468b/lib/zuora/subscription.rb#L47))
  * Refactor logic around [SubscriptionCloudCompatibleVersionFinder](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/8260397dabda85e49c6b7642892c9fd83496fa63/lib/subscription_cloud_compatible_version_finder.rb) & rename

* When removing the cloud license compatible check on manual offline cloud license creation ([code](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/fbeeb5178fe0f004d18e772b70af7b271fcb74ba/app/services/rails_admin/create_license_service.rb#L154)), add a condition that checks the license belongs to a GitLab EE plan now as an extra safety 

## Why 
There is a bug in SFDC that is resulting in the Super Sonics fields occasionally being cleared out. Details of this issue are captured [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4599) and we are working with Sales Systems to correct this problem as part of this epic: https://gitlab.com/groups/gitlab-com/-/epics/1886.
* ~~This is reducing adoption of Cloud Licensing as these customers are receiving only the Legacy mailer (which does NOT have an activation code) and they cannot access the activation code from within CustomersDot~~
* This is actually causing customers to receive the activation code mailer _without_ a cloud license attached, which is a terrible customer experience, and could result in us recognizing revenue at the wrong time.

In looking at New and Renewal quotes created after 2022-08-01, about 390 have these fields blanked out.

|   Quote Status          |  TurnOnSeatReconciliation__c  |   # of Primary Quotes    |
|-------------------------|-----------------------------|-------|
| New                     | No                          | 2038  |
|   New                      | Yes                         | 1112  |
|   New                      | (blank)                     | 82    |
| **New Total**               |                             | **3232**  |
| Sent to Z-Billing       | No                          | 4774  |
|  Sent to Z-Billing                       | Yes                         | 3417  |
|   Sent to Z-Billing                      | (blank)                     | 305   |
| **Sent to Z-Billing Total** |                             | **8496**  |
| **Grand Total**            |                             | **11728** |


<details><summary>Example reported in Slack</summary>
https://gitlab.slack.com/archives/C018C623KBJ/p1656623411693169
![image](/uploads/7f285a97705b946eb410eedd7c32a9f0/image.png)
</details>

This also impacts their Customer Portal experience and prevents the customer from accessing their activation code there, so these customers are then downloading legacy licenses from the portal and activating with that. Example of this reported here: https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/459#note_1064490965

### 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 -->

Ensure sufficient test coverage is added to account for these different permutations and conditions..

Story points: 3.0