Extract GitlabSubscriptions::Features class

What does this MR do and why?

In this MR I extracted the "features" related code out of License class and into a new GitlabSubscriptions::Features class.

The reason why I nested this class under the existing GitlabSubscriptions namespace is that:

1. GitlabSubscriptions:: is an existing namespace and each class must be nested to a domain-specific (or feature category) namespace.
2. Features defined here are those available after purchasing a subscription since for GitLab Core we don't need to check feature availability.
3. Customers can purchase either a subscription for SaaS or self-managed but it's still a subscription.
4. Today we have GitlabSubscription model to indicate that a customer bought a SaaS subscription. This probably might need to be renamed to SaasSubscription to be clear.
5. License model is also a subscription but for self-managed. In fact License.current.plan matches one of the plans from our pricing page.
   • On Gitlab.com License.current.plan is Ultimate which means that SaaS is a special self-managed instance with an Ultimate license (so that all features are available) but where each namespace can have a different plan.
   • For this reason I think we could eventually move License to GitlabSubscriptions::License and Plan to GitlabSubscriptions::Plan since these classes should also be nested into a domain namespace.

Notes about the concept of "plans"

• The Gitlab Plan model is what's assigned to a GitlabSubscription (purchase of SaaS license) attached to a namespace. This is why you see ultimate_trial, opensource etc. But it also has default plan which is used on self-managed and that's the only plan self-managed uses. For example a namespace on self-managed always has a default plan. This was done so that we could allow PlanLimits model to be used by self-managed admins to manage application limits.
• The License class manages the installed license in the self-managed instance.
  • It shouldn't know about all features --> this is why I just extracted them out.
  • It has a plan associated to it, which is not the Plan model but a simple string [starter, premium, ultimate] which map the selection in our pricing page. (with starter probably to be discontinued).
  • This ☝ is why License::PREMIUM_PLAN may still make sense than using *_TIER as I originally thought. So, I would stick to the term plan for now.
• Plans defined in Plan contain special plans that allow us to better manage SaaS subscriptions like *_trial or opensource (e.g. giving users on Ultimate Trial Ultimate features but Free plan limits). But License::*_PLANs must be a subset of Plan.all_plans

References

The idea of this refactoring was inspired by conversation we had in !80800 (closed) to try to understand how License/Plan/subscriptions could be better described in code.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.