Include Registration Features check in SSoT method for license check
## Problem Currently we have created many issues in https://gitlab.com/groups/gitlab-org/-/epics/8977+ to get teams to move more features into Usage Pings. These [instructions](https://gitlab.com/gitlab-org/gitlab/-/issues/422273#instructions "Registration Features - Group file templates") are complex and have introduced a number of duplications and inconsistencies in our codebase: - Where we had `License.feature_available?` we now have `License.feature_available?(:the_features) || ::GitlabSubscriptions::Features.usage_ping_feature?(:the_feature)` - In some cases we introduced a different pattern like `lib/gitlab/registration_features.rb` which is inconsistent with the other feature checks. - We don't know whether we fixed all license checks because some of they may be dynamic (using metaprogramming). This could introduce bugs and inconsistencies. - This pattern is not future-proof because we now have to always use the 2 conditions everywhere from now on. This represents a lack of SSoT. ## Goal Transform the `License.feature_available?` check into the SSoT check that returns if a feature is available at instance level, whether it's from the purchased license/tier or from the instance admin having enabled Usage Pings (so you get extra features for that). ## Cyclical dependency problem We know that [we previously attempted](https://gitlab.com/gitlab-org/gitlab/-/issues/334503#note_683872123 'Follow-up from "Enable EE registration features for UsagePing"') to incorporate usage ping feature check inside `License.feature_available?` but we decided not to do that because of some cyclical dependencies: ```mermaid flowchart LR Gitlab::CurrentSettings --> ApplicationSetting --> Gitlab::ImportSources --> License.feature_available? --> Gitlab::CurrentSettings ``` However, these cyclical dependencies are located within `ApplicationSetting` when using `License.feature_available?`. We should be able to skip the check for usage ping features due to cyclical dependencies in these few instances of the codebase. This way we have made the problem of cyclical dependencies explicit rather than implicit. The cyclical dependencies are not wide-spread and they are specifically located within an area of code that deals with initialization. We can deal with cyclical dependencies later if we have a good way to identify them in code. This should not prevent us from using a much more common pattern for license check and making it the SSoT. ## Iterations * [x] Make `License.feature_available?` the SSoT for license checks * [x]   https://gitlab.com/gitlab-org/gitlab/-/issues/422614+s * [x] Update [instructions](https://gitlab.com/gitlab-org/gitlab/-/issues/422273#instructions "Registration Features - Group file templates") in the existing issues * [ ] Cleanup unnecessary code in `lib/gitlab/registration_features.rb` and unnecessary conditions added so far * [ ] Explicitly define which features cannot easily be moved to usage pings (like `custom_project_templates` due to cyclical dependencies)
epic