giseldo/neodataset huggingface dataset:
Remove Timecop references

### Problem

My VS Code extension for rubocop was complaining about a couple of invalid cops involving Timecop.  

```
.rubocop.yml: RSpec/TimecopFreeze has the wrong namespace - should be Gitlab/RSpec 
.rubocop.yml: RSpec/TimecopTravel has the wrong namespace - should be Gitlab/RSpec 
```

As it turns out, the Timecop gem was removed over a year ago in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3202.  With that gem removed, there isn't much use for these cops.

### Proposal

There are a couple of things we can do to clean up after Timecop was removed:

- [x] Remove the custom cops, `RSpec/TimecopFreeze` and `RSpec/TimecopTravel` https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6166
- [x] Rename the custom Rspec metadata tag `timecop`.  We could use 2 separate tags instead, `travel_to` and `freeze_time`, which are a little more descriptive anyway. https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6167

Story points: 1.0
Update or remove `customers:update_country_for_invalid_customer_objects` task

### Proposal

The [rake task](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/48829db15325c6d7b71e1c004c397db8c632a7dc/lib/tasks/data_maintenance/update_country_for_invalid_customer_objects.rake#L13) `customers:update_country_for_invalid_customer_objects` queries the `zuora_account_id` column on Customer multiple times.  We should consider whether we need this rake task going forward.  If not, we should delete it.  If so, let's update it to use the new billing account structure when the `account_data_structure` feature flag is enabled.

Story points: 1.0
Consider removing `zuora:export_vat_id` task

### Proposal

The [rake task](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/965b897c955a9375cc72afae414f6245af2a33ff/lib/tasks/zuora.rake#L3) `zuora:export_vat_id` fetches CDot Customer records where `vat_code` is present and updates the Zuora Account if the `vat_code` does not match in Zuora.  This task was introduced over 3 years ago, so if we haven't used it since then, we should consider removing it to avoid updating it for the new account data structure.

Story points: 1.0
Update `clear_missing_zuora_account_ids` task

### Proposal

The `customers:clear_missing_zuora_account_ids` [rake task](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/c38384799ec82d24f23bc21053cef90a5ff88613/lib/tasks/clear_missing_zuora_account_ids.rake#L10) queries the Customers table using the `zuora_account_id` column.  This should be updated as follows:

* When :account_data_structure enabled
  * Base the [`zuora_account_relation`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/c38384799ec82d24f23bc21053cef90a5ff88613/lib/tasks/clear_missing_zuora_account_ids.rake#L20) on the `BillingAccount` model
* When :account_data_structure disabled
  * Leave the `zuora_account_relation` as-is, based on the `Customer`

Updating the CustomersDot records, both `Customer` and `BillingAccount`, has already been addressed.

Story points: 1.0
Update FindOrCreateCustomerService

### Proposal

The `FindOrCreateCustomerService` [references `customer.zuora_account_id?`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/350e078423a0ffb5229731c2991b04e24dbaaf73/app/services/find_or_create_customer_service.rb#L111) which is a magic Rails method that checks the presence of the `zuora_account_id` column on the customer.  This will need to be updated to check for presence of a `BillingAccountMembership` when the `account_data_structure` feature flag is enabled.

### 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 -->

All references in tests should also be updated/deleted.

Story points: 1.0
Update Customer queries using zuora_account_id

### Proposal

There are multiple places in the app that query a CDot Customer using the `zuora_account_id` column.  When the `account_data_structure` feature flag is enabled, the BillingAccountMembership should be used to fetch the first Customer associated with the BillingAccount.

- [`Subscription#sold_to_customer`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/95e76dcb7a135079d7bdc7ad511bce9ce95c573c/app/models/subscription.rb#L650)
- [`SeatLinkCreateService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/4ae39fa629f11d88d5575837412df990e624b9a5/app/services/seat_link_create_service.rb#L116)
- [`SyncUpOrderCustomerService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/29a6c940afb709517efed7002d37be47edc6a280/app/services/sync_up_order_customer_service.rb#L25)

### 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 -->

Tests should be updated, including Model specs to ensure that that...

> BillingAccountMembership should be used to fetch the first Customer associated with the BillingAccount.

Think about any permutations / exceptions that might occur with fetching the `first` vs `last`.

Story points: 2.0
Update RetryDeclinedReconciliationJob

### Proposal

[The `subscription_names` method](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e9eaf1283947f750b763c9e179626f0bbb341284/app/jobs/retry_declined_reconciliation_job.rb#L51) in `RetryDeclinedReconciliationJob` finds subscriptions in Zuora by first fetching the first CDot Customer that matches the `zuora_account_id`.  This code should be refactored to query Zuora Subscriptions directly using `zuora_account_id` and not use the `Customer` model.  The `account_data_structure` feature flag should not be necessary to use if querying Zuora Subscriptions directly.

Another option that would require the feature flag: Consider fetching the subscriptions via the matching `BillingAccount` instead of the `Customer` as it also has access to the `raw_subscriptions` method.

### 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 -->

Tests might need to be updated / created to ensure that this method does indeed send the request.  It might be prudent to also use a mock to mock the Zuora API so we are not surprised by a rogue response.

Story points: 1.0
Refactor Invoices to use Account instead of Customer

### Proposal

References of `current_customer.zuora_account_id` in [`InvoicesController`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e9eaf1283947f750b763c9e179626f0bbb341284/app/controllers/invoices_controller.rb#L35) could be updated to `current_zuora_account.id` because the `require_zuora_account` before_action is used.  Using `current_zuora_account` is preferable as it allows us to transition to multiple billing accounts per customer more easily, as this would be fewer places to update in a later iteration.

More importantly, the [`InvoicesFinder`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/ccc5b4d03aaa3929ab72b3a36fdc7b6eb14d672c/app/finders/invoices_finder.rb#L3), which is only [referenced once](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e9eaf1283947f750b763c9e179626f0bbb341284/app/controllers/invoices_controller.rb#L11) in the app the `InvoicesController`, can be refactored as well.  This service should accept a `Zuora::Account` instead of a `customer`, as all that is used from customer is `zuora_account_id`.

Story points: 2.0
Redefine zuora_account_id in the Customer model

### Problem

There are many places in the app where the `zuora_account_id` attribute is referenced Customer.  However, when the `account_data_structure` feature flag is enabled, we want to avoid using this attribute.  Instead, the Customer's membership to a BillingAccount should be used.

### Proposal

The easiest way to iterate towards a solution is to override the `zuora_account_id` getter method that ActiveRecord provides.  Something like the following might work:

```ruby
# customer.rb

def zuora_account_id
  if Unleash.enabled?(:account_data_structure)
    billing_accounts.pick(:zuora_account_id)
  else
    super
  end
end
```

We should consider memoizing this method as well to avoid multiple queries to billing_accounts, if the `zuora_account_id` is referenced multiple times (which it must be in some places).

This will allow us to continue using `customer.zuora_account_id` throughout the app but use the new BillingAccount structure to fetch the `zuora_account_id` when the feature flag is enabled.  

I think there could be places where we reference `zuora_account_id` from a Customer where we want the actual attribute instead of the overridden method (iow. value from the BillingAccount), even after the feature flag is enabled.   These could be updated to pull directly from the attribute (e.g. `customer['zuora_account_id']`) instead of using `customer.zuora_account_id`.  The [backfill rake tasks](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/361c240649937ca9d00c9e74837f3ea7902496a8/lib/tasks/data_maintenance/billing_accounts/backfill_with_customers.rake#L17) for example.

This will apply to many usages throughout the app, including these below:
- [`Customer#mark_as_confirmed`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/95e76dcb7a135079d7bdc7ad511bce9ce95c573c/app/models/customer.rb#L61)
- [`Customer.update_zuora_contact`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/95e76dcb7a135079d7bdc7ad511bce9ce95c573c/app/models/customer.rb#L59)
- [`UpdateContactService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/361c240649937ca9d00c9e74837f3ea7902496a8/app/services/update_contact_service.rb)
- [`PaymentFormsController`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/9ae796fa8060281378ff6800f2ad0aefa582821b/app/controllers/payment_forms_controller.rb#L50)
- [`CustomersController`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/8c832b035b30960fcae88a517ffd25b524784a1e/app/controllers/api/customers_controller.rb#L41)

Story points: 2.0
Use billing_account instead of customer_id on Orders

### Problem

As of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4804+, the `billing_account_id` column exists on Orders.  The `BillingAccount` has a `zuora_account_id` attribute which should be the SSoT for the association to the Zuora Account.  The `BillingAccount` also has memberships with Customers.  However, the Orders table still has a reference to the `customer_id` as well.  There are likely many places where the billing account associated with the Order should be used instead of the Customer.

### Proposal

When the `account_data_structure` feature flag is enabled, the `billing_account` associated with the Order could be used instead of `customer` in many cases.  For example, when the customer is used simply to access the Zuora Account.  In other cases, we could access customers through the billing account memberships.

We will eventually remove the `customer_id` from Orders as part of https://gitlab.com/groups/gitlab-org/-/epics/8949+ in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4805+.

Story points: 5.0
Use billing_account instead of zuora_account_id on Orders

### Problem

As of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4804+, the `billing_account_id` column exists on Orders.  The `BillingAccount` has a `zuora_account_id` attribute which should be the SSoT for the association to the Zuora Account.  However, the Orders table still has a reference to the `zuora_account_id` as well, leading to confusion about which field should be used.

### Proposal

When the `account_data_structure` feature flag is enabled, the `billing_accounts.zuora_account_id` associated with the Order should be used instead of `orders.zuora_account_id`.  We will eventually remove the `zuora_account_id` from Orders as part of https://gitlab.com/groups/gitlab-org/-/epics/8949+ in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5127+.

Story points: 3.0
Update Salesforce::FindAccountService

### Problem

There are places in the application where `salesforce_account_id` is referenced from `Customer` (to be renamed `User`), when the `:account_data_structure` feature flag (introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4794) is enabled, the `Customer`'s `BillingAccountMembership` should be used instead.

**This issue** proposes to update `Salesforce::FindAccountService` to rely on the BillingAccount model and associated record when the `:account_data_structure` feature flag is enabled.

Note: The legacy code will be removed in a later issue once the feature flag has been vetted and promoted in production.

### Proposal

Changes from https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5389+ should solve for the conditional to decide if the value needs to be updated within CDot.

[ADD] Update `salesforce_account_id` for `customers` **and** the `billing_accounts` records to keep them in sync

### Result

- Always update both `salesforce_account_id` values to keep them in sync

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Update clear_missing_salesforce_account_ids task

### Problem

There are places in the application where `salesforce_account_id` is referenced from `Customer` (to be renamed `User`), when the `:account_data_structure` feature flag (introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4794) is enabled, the `Customer`'s `BillingAccountMembership` should be used instead.

**This issue** proposes to update `clear_missing_salesforce_account_ids` to rely on the BillingAccount model and associated record when the `:account_data_structure` feature flag is enabled.

Note: The legacy code will be removed in a later issue once the feature flag has been vetted and promoted in production.

### Proposal

- When :account_data_structure enabled 
  - Base the `salesforce_account_relation` on the `BillingAccount` model 
- When :account_data_structure disabled 
  - Leave the `salesforce_account_relation` as-is, based on the `Customer` 

When updating the CustomersDot records based on the SFDC `missing_account_ids` update both:
- [LEAVE AS-IS] Update the customer `salesforce_account_id` to `nil`
- [ADD] Update the billing account `salesforce_account_id` to `nil` 

### Result

- The SSoT model is used depending on the `:account_data_structure` feature flag status.
- Always update both `salesforce_account_id` values to keep them in sync

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Test Cleanup Logic Refactor

:bulb: Consider moving this to a cooldown, cleanup dedicated interval:
- Post https://gitlab.com/groups/gitlab-org/-/epics/8950+
- Pre https://gitlab.com/groups/gitlab-org/-/epics/8951+

### Problem

We want to remove duplicated logic from `TestAccountCleanupCronJob` and `TestDataCleanupTask` to avoid these diverging in the future as a result to changes on one but not the other. Ultimately conceptually feels like this logic should be similar.

### Proposal

Consolidate logic from `TestAccountCleanupCronJob` and `TestDataCleanupTask`
1. Extract the cleanup logic into a service including:
  - `remove_zuora_data`: extract to be reused
  - `remove_sf_data`: extract to be reused
  - `customer` deletion
1. Look into using `request_with_retries` in this consolidated logic by either:
  - using it consistently for all cases (I like this approach)
  - passing a `retry:` parameter.
- Call the new cleanup service directly from `TestAccountCleanupCronJob` and `TestDataCleanupTask`

### Acceptance Criteria

- New service is created, tested and set to replace the old logic.
- Old tests pass mostly unchanged.

Story points: 2.0
Redefine salesforce_account_id at the customer level

### Problem

There are places in the application where `salesforce_account_id` is referenced from `Customer` (to be renamed `User`), when the `:account_data_structure` feature flag (introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4794) is enabled, the `Customer`'s `BillingAccountMembership` should be used instead.

**This issue** proposes to redefine the `salesforce_account_id` meaning at the `Customer` instance level to use its related billing account based on the status for the `:account_data_structure` feature flag.

Note: The legacy code will be removed in a later issue once the feature flag has been vetted and promoted in production.

### Proposal

Redefine `customer#salesforce_account_id` method to:

```ruby
def salesforce_account_id
  strong_memoize(:salesforce_account_id) do
    if Unleash.enabled?(:account_data_structure)
      billing_accounts.pick(:salesforce_account_id)
    else
      super
    end
  end
end
```

FYI, we might not be able to use `strong_memoize` to memoize the feature flagged code.  I ran into problems unit testing with this implementation.  In https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6164, I ended up using `@zuora_account_id ||= billing_accounts.pick(:zuora_account_id)` instead.

This should account for all the simple / direct usages of the `salesforce_account_id` in the context of:
- `Salesforce::CreateAccountWorker`
- `Update `CreateSalesforceContactService`
- `TestAccountCleanupCronJob` (refactor recommended: Issue 2)
- `TestDataCleanupTask` (refactor recommended: Issue 2)
- `Api::CustomersController`

### Acceptance criteria

1. `salesforce_account_id` is used from the customer when the `:account_data_structure` feature flag is disabled.
1. `salesforce_account_id` is used from the customer's associated billing account when the `:account_data_structure` feature flag is enabled.
1. The impact of the change in the mentioned simple / direct users of the value is validated / tested.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Instrumentation for ramp subscriptions display

### Proposal

Instrument the following actions on the ramp subscription card:

1. `Change subscription` button click (with saas/sm differentiation)
2. `Link subscription to a group` button click

| Event Action | Event Label | Event Category | Location |
|----------------|--------------|-------------|----------|
| click_button | change_subscription_ramp_saas/change_subscription_ramp_sm | Webstore | */subscriptions/* |
| click_button | link_nampespace_ramp | Webstore | */subscriptions/* |

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Add action buttons section to subscription-v2 component

<!-- 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/

-->
### Proposal
Add the action buttons section to 
1. Link subscription to GitLab group (only in case of SaaS)
2. Change subscription button which renders a modal telling the customer to get in touch with the sales team to make changes to the subscription.  

![image](/uploads/1caaae6af3fe0cf163f5dcc63d5d324c/image.png)
![image](/uploads/c71e548e01c5a5ff8065cf6e0a6c3b46/image.png)
![image](/uploads/6eb7f706e25f3a21ee01c58a450935fb/image.png)

<!-- 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?

**Design:** https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3916/

Story points: 2.0
Add subscription activation section to subscription-v2 component

<!-- 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/

-->
### Proposal
Add the subscription activation section to the subscription-v2 component which can be used by the customer to activate their SM subscription.
![image](/uploads/561ab3d4534025c6c096ed9ed1d822e5/image.png)

<!-- 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?

Design: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3916

Story points: 1.0