Introduce for_active_add_ons query scope

What does this MR do and why?

We are moving away from AvailableServices. In this class, we currently use the add_on_purchases helper to determine whether the add_on_names defined by this service have actually been purchased for the given instance or namespace.

In this MR, we:

1. Move this logic into an API owned by groupprovision instead of groupcloud connector.
2. Adjust the logic to better reflect the various requirements we have, such as:
   1. The namespace should only stick if we're actually on gitlab.com.
   2. Replace self_and_ancestor with root_ancestor since we do not attach billing records to sub-namespaces.

This change is behind the feature flag cloud_connector_new_purchase_lookup. In subsequent MRs, we will be replacing calls to the existing purchased? and add_on_purchases methods with this new API instead.

This change is primarily a refactor and not user-facing.

References

• #542422 (closed)

How to set up and validate locally

1. In rails console run `Feature.enable(:cloud_connector_new_purchase_lookup)
2. In rails console run

   GitlabSubscriptions::AddOnPurchase.for_active_add_ons(['duo_core'])

• On self-managed: This should only return the Duo Core add-on.
• On gitlab.com: The result should be empty because no namespace is provided.
  • With namespace: <group> set: This should only return the Duo Core add-on.

MR acceptance checklist

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

Related to #542422 (closed)