Cloud License activation failure when future dated renewal and past subscription trueups

# Bug

## Summary

When activating a cloud license for the first time (especially when coming from legacy), the cloud license is generated using the subscription version that better "fits" the activation moment / date.

Per @vshumilo:

> The subscription version is resolved [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/df807833e9e1b346bde9a0c0d2adf37a6ab89209/app/models/cloud_activation.rb#L23) using [this logic](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/df807833e9e1b346bde9a0c0d2adf37a6ab89209/lib/zuora/subscription.rb#L70-L72)
> 
> Additional context
> - This decision was per-design to allow a customer that is in the middle of a subscription term to upgrade to cloud license we decided to use the current subscription version (applicable at the moment of the activation)
> - The specific logic on how this current subscription is resolved changed ~1 month ago, current one should be more accurate. Is this something you have seen reported in the last month or since the release of cloud activation?

However, in some cases when the following conditions are also true:

1. A future-dated renewal amendment exists
2. The current, pre-renewal version of the subscription has true-ups

The cloud license being generated is failing to activate until at least the start date of the renewal term when the license gets generated with the most recent version of the subscription.

It seems to be related to true-up checking (documented in at least 2 of the reported examples), and possibly current billable users since the trueup logic includes a [fallback check on current users](https://gitlab.com/gitlab-org/gitlab/-/blob/066245b248aa8df95958302656b252705d0f74fc/ee/app/models/license.rb#L507-508) that would normally be skipped in cloud licenses.

Currently unknown why the true-up logic would be failing, even for the current (non-renewal) term; in theory it should be generating a license that works the same as it did at the start of the current term.  It's using `trueup_from` and `trueup_to` of the current period, in other words, `trueup_from == current_starts_at - 1 year` and `trueup_to == current_starts_at`

[example ticket](https://gitlab.zendesk.com/agent/tickets/329201)  
[example customer](https://customers.gitlab.com/admin/customer/205112/edit)  
[example cloud license](https://customers.gitlab.com/admin/license/1043282)

## Steps to reproduce

1. Be on legacy license
2. Have your current term subscription include true-ups
3. Adjust user counts in a way that prevents your current license from being reactivated
   - Either increase your billable users count, or your max historical (for current term)
4. Try to convert to cloud license prior to renewal

## Proposed fix

It's really the trueup logic at fault here, since that both re-validates current term trueups and also contains a current users check (which would be skipped without `License#check_trueup` being called).  Because these numbers can change over the course of a year, re-activating the current term license may be impossible.

Sidenote: Perhaps this highlights the [discussions in this issue](https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/511).

1. Skip all of `License#check_users_limit`, `License#check_trueup`, and `License#check_restricted_user_count` when renewing or prior to renewing from legacy to cloud license the first time.
 
## Workarounds

1. Wait until start date of the renewal period

## Reported examples

1. https://gitlab.zendesk.com/agent/tickets/329201
1. https://gitlab.zendesk.com/agent/tickets/325200
1. https://gitlab.zendesk.com/agent/tickets/322732
1. https://gitlab.zendesk.com/agent/tickets/324490
2. https://gitlab.zendesk.com/agent/tickets/328920
3. https://gitlab.zendesk.com/agent/tickets/340797
4. https://gitlab.zendesk.com/agent/tickets/342180
5. https://gitlab.zendesk.com/agent/tickets/342994 (result of manual legacy)
6. https://gitlab.zendesk.com/agent/tickets/344686 (result of manual legacy)
7. https://gitlab.zendesk.com/agent/tickets/360298 (result of manual legacy)
8. https://gitlab.zendesk.com/agent/tickets/375405 (current billable, `check_restricted_user_count`)

<!---
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