New users should have admin approval if User Cap setting is exceeded

What does this MR do?

This MR implements the User cap setting functionality for new users:

• Any new user (self registered or created by an admin) is placed in blocked_pending_approval state when the User cap setting is enabled.
• After the user is created, a job will run to check if the user can be activated without exceeding the User cap setting:
  • If the User cap is not exceeded, the user will be activated automatically.
  • If the User cap is exceeded, the user is kept in blocked_pending_approval state and only the admin can approve them manually.

Notes

⚡ The Require admin approval for new sign-ups setting is now enabled by default for new instances. #267568 (closed)

⚡ The User cap setting is behind a disabled feature flag. After removal of the feature flag this setting will be disabled by default and opt-in only. &4315

⚡ In case an admin wishes to re-enable open registration (given they don't have Require admin approval for new sign-ups enabled) they will need to increase the User Cap or set it to nothing (so no limit is applied).

Context

#211390 (closed) introduced the User Cap setting which defines the max amount of billable users there can be in the instance. After that maximum number is reached, the instance admin has to review and approve any new user by navigating to Admin Area > Overview > Users > Pending Approval tab.

Users that register to an instance where User cap is set to a number see this message when their account is created:

Related issue

#244519 (closed)

Does this MR meet the acceptance criteria?

Conformity

• [-] Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team