Instance not able to seat link using existing cloud license

### Problem

As described in these Slack threads ([first](https://gitlab.slack.com/archives/C029YFPUA6M/p1637926425309000) and [second](https://gitlab.slack.com/archives/C01BPM66KNE/p1638280781120700)), [a customer](https://customers.gitlab.com/admin/customer/221264) who was previously using a license file for their SM subscription ([link to Zuora subscription](https://www.zuora.com/apps/Subscription.do?method=view&id=8a129bb27d37d510017d3a23c8b814a6)), renewed their subscription (on Nov 19) before it was set to expire on Nov 24.  They decided to activate the renewed subscription on Nov 22.  The customer was understandably confused because the new synced cloud license showed information from the subscription term that was about to expire.  They waited until Nov 24 to see if the new subscription details would be synced but found they didn't sync.  Attempts to manually sync the subscription were also unsuccessful.

On Nov 24, when the new subscription term was set to start, CustomersDot received a seat link request at 03:26:17 and a [cloud license](https://customers.gitlab.com/admin/license/1009153) was generated for the new term, but this license didn’t seem to get persisted to the instance. Because the new license didn’t get persisted, all future seat link attempts from the instance (auto or manual) used [its current (outdated) license](https://customers.gitlab.com/admin/license/1009081) key.  In this particular case, it appears the seat link requests for the previous day (report_timestamp = 2021-11-23 12:00:14) updated the LicenseSeatLink records instead of creating new ones.  As part of that update, the `license_id` was updated to [the new cloud license](https://customers.gitlab.com/admin/license/1009153).  The link to the instance’s license was lost.

We can see this in the previous versions of this LicenseSeatLink:
```
license seat link (ver 1):
  id: 2832633
  report_timestamp: 2021-11-23 12:00:14
  updated_at: Tue, 23 Nov 2021 15:59:57
  license_id: 1009080

license seat link (ver 2):
  updated_at: Tue, 23 Nov 2021 16:02:36
  license_id: 1009081 (a new license because customer `name` changed)

license seat link (ver 3):
  updated_at: Wed, 24 Nov 2021 03:26:17
  license_id: 1009153 (a new license because `users_count` changed to 30)
```

This meant the [lookup here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/8c1409ed275594ae63487d1fb85a726297c296f5/app/controllers/api/v1/seat_links_controller.rb#L59) to find the `SelfManagedInstanceActivation` record will no longer work with the existing license.  That’s why we see from Nov 24 until a workaround was used to fix seat link that all `LicenseSeatLink` records created (between nov 24 to 30) did not have a corresponding `license_id` (because they were not considered part of "cloud sync".

### Proposal

CustomersDot should avoid updating `license_id` in the `SeatLinkCreateService`, and instead simply add a new `LicenseSeatLink` record instead.  If this logic were used, the next manual or auto seat link request from the customer's instance likely would have resolved the seat link connection and persisted the license for the new term.

Story points: 2.0