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.
Fixesgitlab-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 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.