Check email confirmation status of active users

What does this MR do and why?

Related to: https://gitlab.com/gitlab-org/modelops/anti-abuse/team-tasks/-/issues/774

The anti-abuse team recently rolled out Iteration 1 of identity verification. This iteration introduced an "opt-in" identity verification flow where users could choose to perform identity verification (phone or credit card) in exchange for in-app privileges such as running CI jobs or creating many top-level groups.

The introduction of the opt-in flow has subtle differences from the identity verification that is performed when a user signs up. Unfortunately, a bug was introduced that caused users with unconfirmed email addresses from not being able to access to product due to a conflicting identity verification state. This MR changes how we determine if a user should experience the opt-in flow by checking that they have logged in and have a confirmed email address. Previously, we were only checking if a user had logged in before which caused the opt-in identity verification methods to be required during the signup flow.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. Simulate SaaS mode in GDK

export GITLAB_SIMULATE_SAAS=1

2. Setup your GDK to work with identity verification.

::Gitlab::CurrentSettings.update(email_confirmation_setting: 'hard')
::Gitlab::CurrentSettings.update(require_admin_approval_after_user_signup: false)
Feature.enable(:identity_verification)
Feature.enable(:opt_in_identity_verification)
Feature.enable(:identity_verification_phone_number)
Feature.enable(:identity_verification_credit_card)

3. Prior to these changes (master branch), we determined which verification methods are required for a user based on whether that user was active or not. In this example when a user is active but does not have a confirmed email address the signup_identity_verified? method returns false but the identity_verification_state makes it appear like the user has completed identity verification.

[3] pry(main)> admin = User.first
=> #<User id:1 @root>
[4] pry(main)> user = Users::CreateService.new(admin, { name: 'new_user123', username: "new_user123", email: "new_user123@gmail.com"}).execute
=> #<User id: @new_user123>
[5] pry(main)> user.confirmed?
=> false
[6] pry(main)> user.update(last_sign_in_at: Time.now)
=> false
[7] pry(main)> user.last_sign_in_at
=> Mon, 17 Jun 2024 22:02:51.685615381 UTC +00:00
[8] pry(main)> user.signup_identity_verified?
=> false
[9] pry(main)> user.identity_verification_state
=> {"phone"=>false}

4. When you switch to the MR branch and re-run the commands you can see that the user needs to verify their email address.

[15] pry(main)> user.signup_identity_verified?
=> false
[16] pry(main)> user.identity_verification_state
=> {"email"=>false}