Fix Member Activate and Await Service

What does this MR do and why?

Related issue: https://gitlab.com/gitlab-org/gitlab/-/issues/362200

Fix Members Activate and Await Service

It's possible for membership records to be invalid when the inherited access_level is higher (see #362091 (closed)). When using the state machine to transition between membership states, it would validate the records and therefore fail to change the state.

To prevent this bug from happening we skip the validation by using update_all. To still guarantee valid data, we moved the validation and restrictions to the Members::ActivateService and Members::AwaitService.

• We now call UserProjectAccessChangedService when setting a member to be awaiting, which runs otherwise as an after_commit hook.
• We check the free user cap limits when activating a user.
• We prevent the last owner to be set to awaiting.
• We don't allow a user to set themselves to be awaiting anymore.

Screenshots or screen recordings

How to set up and validate locally

export GITLAB_SIMULATE_SAAS=1
bin/rails c

ApplicationSetting.first.update(check_namespace_plan: true)
Feature.enable(:free_user_cap)

1. Go to the Usage Quota page (Group -> Settings -> Usage Quota)
2. Toggle users on/off.

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.