Verify Arkose Labs session token and record user data on sign up

This MR is the third of a multi-MR change to integrate Arkose Labs to the registration flow.

1. Display Arkose Labs challenge in the registration form
2. Split Arkose::UserVerificationService into Arkose::TokenVerificationService and Arkose::RecordUserDataService
3. Verify Arkose Labs session token before registration and record Arkose Labs user data after registration 👈🏼 👈🏼 👈🏼 YOU ARE HERE

What does this MR do and why?

This MR is the second iteration to integrate Arkose Labs challenge into the registration flow. It adds backend code to

1. implement verification of the Arkose Labs session token passed from the frontend
2. allow or prevent registration depending on the verification result
3. persist Arkose Labs data for the newly created user

Screenshots or screen recordings

success

How to set up and validate locally

1. Turn on :arkose_labs_signup_challenge feature flag through Rails console

   $ rails console
   > Feature.enable(:arkose_labs_signup_challenge)

2. Set up credentials for Arkose Labs. Credentials are available in GitLab 1Password Engineering Vault

   $ rails console
   > ApplicationSetting.first.update({ arkose_labs_public_api_key: '****', arkose_labs_private_api_key: '****', arkose_labs_namespace: 'client' })

3. Force Arkose Labs to always require the user to solve the challenge. Update ee/app/assets/javascripts/arkose_labs/components/sign_up_arkose_app.vue

   arkoseObject.setConfig({
     data: { id: 'ML_defence' }, // ADD THIS LINE
     mode: 'inline',
     selector: `.${this.arkoseContainerClass}`,
     onShown: this.onArkoseLabsIframeShown,
     onCompleted: this.passArkoseLabsChallenge,
   });

4. Visit the registration page at http://localhost:3000/users/sign_up
5. Validate that the challenge is shown
6. Validate that a new user can be created when the challenge is solved
7. Validate that Arkose Labs data for the new user is persisted

   $ rails console
   > new_user = User.last
   > new_user.custom_attributes.all
   => [#<UserCustomAttribute:0x00007f806d0dd348
     id: 37,
     created_at: Thu, 01 Sep 2022 07:07:56.413298000 UTC +00:00,
     updated_at: Thu, 01 Sep 2022 07:07:56.413556000 UTC +00:00,
     user_id: 108,
     key: "[FILTERED]",
     value: "45063105a2f9c0707.8193498204">,
    #<UserCustomAttribute:0x00007f806d0dd0a0
     id: 38,
     created_at: Thu, 01 Sep 2022 07:07:56.413298000 UTC +00:00,
     updated_at: Thu, 01 Sep 2022 07:07:56.413556000 UTC +00:00,
     user_id: 108,
     key: "[FILTERED]",
     value: "Low">,
    #<UserCustomAttribute:0x00007f806d0dcec0
     id: 39,
     created_at: Thu, 01 Sep 2022 07:07:56.413298000 UTC +00:00,
     updated_at: Thu, 01 Sep 2022 07:07:56.413556000 UTC +00:00,
     user_id: 108,
     key: "[FILTERED]",
     value: "20">,
    #<UserCustomAttribute:0x00007f806d0dcc40
     id: 40,
     created_at: Thu, 01 Sep 2022 07:07:56.413298000 UTC +00:00,
     updated_at: Thu, 01 Sep 2022 07:07:56.413556000 UTC +00:00,
     user_id: 108,
     key: "[FILTERED]",
     value: "0">]
   >

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.