Follow-up from "Implement checking for the add-on seat for chat users"

The following discussion from !142800 (merged) should be addressed:

• @nmilojevic1 started a discussion: (+3 comments)

  for .com instance, we will govern this change by using purchase_code_suggestions feature flag and service_start_date defined in customers dot portal

  @mksionek My understanding was that we are going to rollout this via purchase_code_suggestions feature flag for Gitlab.com. But I would agree that it would be better if we remove human factor, so there is no need for someone to flip the flag on a particular Cut-off time and date. But in that case, if we rely on service_start_date, do we need a feature flag?

  Unfortunately, we are synchronizing with CDOT only for self-managed customers. The job does not run for GitLab.com. This means that for Gitlab.com, the service_start_date will be always empty.

  ---

  I guess since Gitlab.com is in our control we could just store the values in some data migration:

  ca = CloudConnector::Access.new
  ca.data = { available_services: [{ name: "duo_chat", serviceStartTime: "2024-01-15T00:00:00Z" }] }
  ca.save!

  or use the ENV variable in Gitlab.com case.

task

Implement a way to check service start date for .com instance, where we do not have a synchronization between CloudConnector::Access class and CDot.