OAuth and LDAP sign up process when user cap set - activation not happening correctly

Summary

There's been reports (here and here) about SAML/OAuth login not working correctly when imposing restrictions upon sign up.

Steps to reproduce

Steps to reproduce the bug are detailed in this comment, where the commenter wrote:

If I now set a user cap according to https://docs.gitlab.com/ee/user/admin_area/settings/sign_up_restrictions.html#set-the-user-cap-number,
my newly created SAML user is active immediately.
If I remove the user and the user cap to test again, the newly created user needs approval first.
I tested with a user cap that hasn't been hit yet (5 with only 1 active user).

What is the current bug behavior?

When signing up with a SAML user while the user cap is greater than the number of users but the block_auto_created_users setting is set to true, the newly created SAML user is active immediately.

What is the expected correct behavior?

When signing up with a SAML user while the user cap is greater than the number of users but the block_auto_created_users setting is set to true, the newly created SAML user should be blocked upon creation.

Elements to fix

The fix is twofold:

1. SAML user activation check currently happens in ee/lib/ee/gitlab/auth/saml/user.rb. It should take place in a different spot, more likely in lib/gitlab/auth/o_auth/user.rb.
2. ::Gitlab.config.omniauth.block_auto_created_users is currently used to evaluate whether LDAP users should be blocked upon sign up. This is not correct: for LDAP users, ::Gitlab::Auth::Ldap::Config.new(provider).block_auto_created_users should be evaluated instead.