Collect usage pings `Gcp::Cluster.enabled` and `Gcp::Cluster.disabled`, instead of `Gcp::Cluster.count`

Fixes gitlab-org/gitlab-ce#37648

The initializers including this were doing so at the top level, so every object
loaded after them had a `current_application_settings` method. However, if
someone had rack-attack enabled (which was loaded before these initializers), it
would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't
have that method.

To fix this:

1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need
   `Object.new.current_application_settings` to work.
2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it
   like that in several places.
3. Change the initializers to use that new form.

When sending the usage data, it now includes all pipelines. This commit
will split the pipelines in two; internal and external.

This will lead to historical data being incorrectly marked this way.

Fixes gitlab-org/gitlab-ce#33172

As its hard to reliably check how many review apps there are on the
clients machine, we start by checking where the type is `review`. This
means the folder is called that way. This will lead to a seq
scan on the table. However, this is done once a week, so the benefit of
adding an index seems not to apply here.

This query was timing out and is blocking the sync of usage data for
GitLab.com

CE port of https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1521

This query is constantly generating timeout errors on large installations and we don't
have a simple solution for now and also we don't think having this counter is
really critical.

CE port of https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/735