### Problem The current provisionings for GitLab.com and SM/Dedicated follow markedly distinct approaches. While SM/Dedicated relies on licenses (license key or file) to contain all needed info, GitLab.com relies on multiple syncs for a namespace. To align the provision between the deployment types, the GitLab.com provisioning will be aligned to be similar to the SM/Dedicated. The current multiple syncs to GitLab.com will be replaced by a single sync for a namespace which includes all needed information at once. Each sync will be stored in the database on the CustomersDot side for easier auditing. These records will follow a similar behavior as the license generation for SM/Dedicated and only create a new entry for a sync if the data/info for the new sync has changed compared to the last sync. Timestamps for each sync will still be stored for a better insight into the sync frequency. As part of this work, a new service to trigger the sync was added in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/11450+ as well as a new Sidekiq job in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/11575+ that aren't in use yet. ### Proposal Update current usages of the `Gitlab::Namespaces::UpdatePlanInfoService` to only be executed if the feature flag [`single_namespace_provision_sync`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/322/edit) is disabled. If it's enabled, the new provisioning workflow should be triggered. Whenever possible, the workflow should be triggered via the Sidekiq job introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/11575+ which will handle retries automatically. In places where it needs to be executed in sync (e.g. in the `OrdersControllers`), the result needs to be processed there. The new implementation avoids raising errors whenever possible and returns an error service response instead. This can be leveraged to check for previous exceptions now. ### Result Ability to switch to the new provisioning workflow.