Trigger ArkoseLabs username check on submit

What does this MR do and why?

This follows up on a comment in a previous MR: !82737 (comment 885313542)

This tweaks the ArkoseLabs sign-in flow to trigger a username check when the form is submitted. This ensures that the challenge cannot be skipped by submitting the form without the username field ever losing the focus. If the check determines that the challenge still isn't needed (or if the challenge is being suppressed), the form's submission proceeds normally. Otherwise, the submission is blocked until the user completes the challenge.

Additionally

• This also updates QA tests so that e2e tests performed against staging and production environments wait on the ArkoseLabs challenge to be fully loaded before submitting the sign-in form.
• This also updates UserVerificationService to consider sessions that have the allowlisted telltale (gitlab1-whitelist-qa-team) as verified.

Screenshots or screen recordings

How to set up and validate locally

1. Set the ARKOSE_LABS_PUBLIC_KEY environment variable:

   export ARKOSE_LABS_PUBLIC_KEY="9F5BDFCD-E895-43B5-8D96-B24E0107B685"

2. Restart the GDK in the same terminal you've set the ARKOSE_LABS_PUBLIC_KEY environment variable:

   gdk restart

3. Enable the :arkose_labs_login_challenge feature flag.

   echo "Feature.enable(:arkose_labs_login_challenge)" | rails c

4. Sign out of your instance (or open an incognito browser window) and navigate to the login form at /users/sign_in.

5. Start by filling the password field in.

6. Focus the username field, type-in your username and submit the form by pressing shift + Enter.

Forcing ArkoseLabs challenge's behavior

By following the instructions above, you're relying on ArkoseLabs' decisions on whether or not a challenge should appear. You might want to force it into specific decisions to be able to test all possible outcomes. The setConfig call can be modified to include a data.id property to request specific behaviors:

• 'ML_defence' forces a challenge to appear.
• 'customer_request' results in a suppressed challenge (meaning ArkoseLabs considers your session safe).

Apply the following patch to force a challenge to show up:

diff --git a/ee/app/assets/javascripts/arkose_labs/components/sign_in_arkose_app.vue b/ee/app/assets/javascripts/arkose_labs/components/sign_in_arkose_app.vue
index 45b3ab60a29..af4ce4880e0 100644
--- a/ee/app/assets/javascripts/arkose_labs/components/sign_in_arkose_app.vue
+++ b/ee/app/assets/javascripts/arkose_labs/components/sign_in_arkose_app.vue
@@ -146,6 +146,7 @@ export default {
       const enforcement = await initArkoseLabsScript({ publicKey: this.publicKey });
 
       enforcement.setConfig({
+        data: { id: 'ML_defence' },
         mode: 'inline',
         selector: `.${this.arkoseContainerClass}`,
         onShown: this.onArkoseLabsIframeShown,

Or this patch to simulate a suppressed challenge:

diff --git a/ee/app/assets/javascripts/arkose_labs/components/sign_in_arkose_app.vue b/ee/app/assets/javascripts/arkose_labs/components/sign_in_arkose_app.vue
index 45b3ab60a29..0535c0d0e99 100644
--- a/ee/app/assets/javascripts/arkose_labs/components/sign_in_arkose_app.vue
+++ b/ee/app/assets/javascripts/arkose_labs/components/sign_in_arkose_app.vue
@@ -146,6 +146,7 @@ export default {
       const enforcement = await initArkoseLabsScript({ publicKey: this.publicKey });
 
       enforcement.setConfig({
+        data: { id: 'customer_request' },
         mode: 'inline',
         selector: `.${this.arkoseContainerClass}`,
         onShown: this.onArkoseLabsIframeShown,

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.