Cloud Connector sync: Read license from DB

What does this MR do and why?

We found that when updating license data in one worker, the cloud connector sync worker may be reading stale license data from License.current because it is an in-process cache:

1. sidekiq-server-0: Executes SeatLinkSyncWorker and upon receiving the response, resets the cache behind License.current, but this is an in-memory cache not backed by Redis: https://gitlab.com/gitlab-org/gitlab/-/blob/cb0abad1ac6b11b72b412490e0b98ef36f40b646/ee/app/models/license.rb#L66
2. The worker schedules the CC sync job
3. sidekiq-server-1: Executes SyncServiceTokenWorker and reads License.current -- but if this is processed by a different Sidekiq process, this cache may still hold the older license. This would mean we're requesting a CC access sync for the previous license that we had just replaced

This change makes sure we always read the correct license by loading it from the database by ID. I kept the License.current fallback to make this change backwards-compatible since adding job parameters is considered a breaking change.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

How to set up and validate locally

This is hard to validate locally since it involves timing, distributed sidekiq workers, and cache invalidation to all go hand in hand. I only tested that the entire sync chain still works as expected, which you can do as follows:

1. Run gitlab including sidekiq
2. Activate a self-managed license on http://gitlab.local:3000/admin/subscription
3. Tail the sidekiq job output
4. Look for entries for CloudConnector::SyncServiceTokenWorker and that these jobs succeeded; the job args should now be a hash and not empty anymore

Related to #498456