Over time, `should_check_namespace_plan?` has been re-used from its original intent seen [here](https://gitlab.com/gitlab-org/gitlab/blob/176f56960c7c6d1e18462165b87cc261a4cbdae3/config/application_setting_columns/check_namespace_plan.yml#L8-8) to also be a way to guard SaaS only features. We should resolve this and now follow https://docs.gitlab.com/ee/development/ee_features.html#separation-of-ee-code-in-the-backend for guarding SaaS only features. See [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/174640#note_2244862924). ## Plan We should start working on removing `should_check_namespace_plan?` method and then the application setting behind it as it does pose a significant amount of risk if an instance admin accidentally changes it on SaaS. I believe we can take an approach like this: 1. Use https://docs.gitlab.com/ee/development/ee_features.html#separation-of-ee-code-in-the-backend for the few cases I saw in foss that use this check. 1. Convert explicit uses of [should_check_namespace_plan?](https://gitlab.com/gitlab-org/gitlab/blob/5d49ebdef66b4979fcdb07563c99c1393b4d9d76/ee/app/models/ee/application_setting.rb#L407-407) to use `::Gitlab::Saas.feature_available?(:gitlab_com_subscriptions)` instead, leaving the original intent of this attribute in place. 1. Permanently disable rubocop check for [should_check_namespace_plan?](https://gitlab.com/gitlab-org/gitlab/blob/5d49ebdef66b4979fcdb07563c99c1393b4d9d76/ee/app/models/ee/application_setting.rb#L407-407) that is used in places it was originally intended for. <details><summary>original description</summary> The following discussion from !174640 should be addressed: - [ ] @engwan started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/174640#note_2244862924): (+9 comments) > Preloading plans is not necessary for self managed instances so we can skip this there. > > Is `Gitlab::Saas.feature_available?(:gitlab_com_subscriptions)` the right check? I started with `Gitlab::com?` but rubocop was complaining. </details>