Renewed subscriptions may not be receiving correct license notifications

### Problem

As described in [this Slack thread](https://gitlab.slack.com/archives/C01BPM66KNE/p1649771693748099), a customer with a recently renewed subscription did not receive the license notification with activation code as expected.  Instead, the customer received the legacy license email.  Here's the original question posed in Slack:

>  It seems that this customer received a legacy email for the activation, not the new SCL Iteration 2 email (with just a cloud license activation code, no legacy license). Do we know what triggered them to get that legacy email with only a license file, and not the cloud activation code? 

- [Zuora Customer Account](https://www.zuora.com/apps/CustomerAccount.do?method=view&id=2c92a0fe5b42d2b0015b5d5229a65433)
- [Zuora Subscription](https://www.zuora.com/apps/Subscription.do?method=view&id=8a128b5f7ffe331f0180182e91f02d66)

On Customer Account page, we can see 4 Zuora callouts sent at 04/11/2022 03:32:33 PDT relating to this renewal.

I found the following statements in the logs (adjusted to remove the customer name) which point to the problem:
```
2022-04-11T10:32:31.736Z pid=3957127 tid=2hvbv class=ZuoraCallbackWorker jid=3bf1bddc773b0f81e865d7ad INFO: {"message"=>"ZuoraCallbackWorker: Sending license notification", "subscription_name"=>"xxxx Renewal Opportunity 2019-04-12"}
2022-04-11T10:32:31.900Z pid=3957127 tid=2fvvz class=ZuoraCallbackWorker jid=3fc57f0fcc89c9432cee98ad INFO: {"message"=>"ZuoraCallbackWorker: Successfully updated the Super Sonics aware field during Subscription Renewal", "customer_id"=>3371, "subscription_name"=>"xxxx Renewal Opportunity 2019-04-12", "cloud_activation_id"=>4038, "super_sonics_aware"=>true}
```

It looks like the license notification is sent before we update the `super_sonics_aware` field on the `CloudActivation`.  If that’s the case, the legacy license email would be [sent here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/d3def14bb4d349b9877a7e141cf347f10639a2ef/app/services/license_notification_service.rb#L32) because the super sonics aware field is not set.

The fix isn’t as simple as just reordering logic in CDot.  This is likely a race condition problem because the super sonics aware field is [updated when processing the renewal amendment](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/8993c11361f2fd925f28c1049f24ae55176d7a49/app/workers/zuora_callback_worker.rb#L136) callout, whereas the license notification is sent when processing the last amendment callout (e.g. the callout for the “active” subscription) which in this case is [the RemoveProduct amendment](https://www.zuora.com/apps/Amendment.do?method=viewInfo&id=8a128b5f7ffe331f0180182e91772d0a).  It looks like the  super sonics aware field just happened to be updated a fraction of a second too late, after the license notification.

The good news is when we fully embrace Zuora Orders, this isn’t a possibility as we process one callout for all actions in an order so no race condition.  I think we may need to make one change in the callout code to ensure the SS aware field is updated earlier.

In the meantime, we need to rethink when the SS aware is set.  Right now we only set the field when processing the renewal amendment, but we need to  assume amendments won’t be processed in order.

### Proposal

CustomersDot could check if a subscription has been renewed since X date (pick a date from last fall) and update the `super_sonics_aware` field when processing any of the callouts (not just the renewal amendment [as is the case here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/8993c11361f2fd925f28c1049f24ae55176d7a49/app/workers/zuora_callback_worker.rb#L137)).  This way we can be sure that the `super_sonics_field` is up-to-date before delivering the license.

Story points: 3.0