Ensure SaaS User Cap is only available for groups with paid subscription

What does this MR do and why?

Relates to: https://gitlab.com/gitlab-org/gitlab/-/issues/349911

As per comment here !77567 (comment 803532785) we want to ensure SaaS User Cap is only available for groups with paid subscription

Screenshots or screen recordings

Not applicable

Why are we not moving forward with this change now

The initial code addition seemed quite simple, adding 1 line on user_cap_available?:

return false unles paid?

However, this caused several issues, making the pipeline fail drastically. I didn't find a way to get a full summary so I counted manually, and we had 97 failures.

The reason for these failures lies on a bit of a complex chain of events that I'll try to document here. Every time we add a member to a group, we call user_cap_reached?, and by calling paid? we retrieve the plan associated with that group by calling actual_plan. The problem is that the gitlab_subscription is associated in a later stage of several tests' code flow, but because actual_plan is memoized, we get errors like Validation failed: Namespace has already been taken.

Tests that try to update the subscription after actual_plan is memoized by using calls like gitlab_subscription.update!(plan_code: plan) will also fail because the group will be referring to the older subscription.

Lastly we have real failures from tests that were written with the assumption that User Caps would be a feature available for any subscription.

The current implementation of this MR solves these problems, but we still have a performance concern, of querying plans table every time we call user_cap_available?.

If we decide to move forward with this constraint (user caps only for paid subscription) the contents of this MR would be a good start

How to set up and validate locally

SaaS User Caps pending members

1. Set Gitlab.com? to return true by changing lib/gitlab.rb
2. Enable saas_user_caps feature flag from rails console. (rails console then Feature.enable(:saas_user_caps))
3. With a group with an Premium or Ultimate plan
4. Make sure the URL http://gdk.test:3000/groups/<my-group>/-/usage_quotas/pending_members renders properly
5. If you visit the above URL in a Free plan, it should render a 404 page

SaaS User Caps banner

1. Set Gitlab.com? to return true by changing lib/gitlab.rb
2. Enable saas_user_caps feature flag from rails console. (rails console then Feature.enable(:saas_user_caps))
3. With a group with an Premium or Ultimate plan
4. Navigate to Settings -> Permissions, LFS, 2FA -> User Cap
5. Set the user cap limit to 1
6. Navigate to the group members
7. Add one or more members (until you are above the user cap limit set in previous step)
8. Navigate to any page in your group, or the group projects
9. You should see an alert that you have pending members
10. If you navigate to a group with Free subscription, the banner should not appear (even if you had pending members set up previously)

SaaS User Caps Settings

1. Set Gitlab.com? to return true by changing lib/gitlab.rb
2. Enable saas_user_caps feature flag from rails console. (rails console then Feature.enable(:saas_user_caps))
3. With a group with an Premium or Ultimate plan
4. Navigate to Settings -> Permissions, LFS, 2FA -> User Cap
5. The User cap field should appear right below Memberships
6. If you navigate to a group with Free subscription the User cap field should not appear

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.