Skip SSO/GMA validation when creating project access token

What does this MR do?

New Project Access Tokens do not show in "Active project access tokens".

A user has attempted to create a Project Access Token with the write_repository scope. Once the "Create Access Token" button has been clicked, the token is displayed to the user but it never appears under Active project access tokens. When checking Kibana, it looks like params are passed and the request to create a token is received, there are no exceptions otherwise. The user creating the PAT is an Owner of the project and another Owner of the same project experienced the same behavior. It seems like it may be specific to this namespace.

@manojmj said:

From an initial investigation, it looks like a failure when trying to add the bot user as member of the project. This step fails, we fail to catch it but the token creation continues anyway - this is my hypothesis. The add_user method always returns the member object (not a boolean), so even for a failed membership creation that fails due to the above mentioned validations, it returns a member object, so according to the code we have now, provision_access acts like true.

do we know if the customer is in a project that is in a group that is either group managed or SAML ... If so, the validation that causes this is here. Both these validations could fail for a project bot user being added as member of these projects.

More details @ #271635 (comment 436496160)

This MR skips SSO and GMA enforcement if user is a project bot. This MR makes it so that PrAT membership addition does not fail if SSO/GMA enforced, and prevents proceeding to the PAT creation stage if membership addition fails for some reason.

Screenshots (strongly suggested)

Now, when there is an error, the token will not be created and an alert will show up on the page telling the user the reason why instead of 500ing

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

Related to #271635 (closed)