Sign In Unless Signed In as Current User for PAT Creation in E2E Tests

What does this MR do and why?

Since adding the GITLAB_QA_ADMIN_ACCESS_TOKEN to gitlab-qa-mirror pipelines, intermittent 403 Forbidden errors continue to persist on qa-master runs (see Multiple 403 Forbidden Errors on QA Tests (#365401 - closed))

A recent failing job where this occurred revealed that in register_spec.rb, on creating a new user via sign up in the UI, this user is never logged out between when it is fabricated and when the TestResourceDataProcessor collects the fabrication and determines a resource_api_path for deletion. From there, the api_delete_path for the user resource is defaulted to "/users/#{fetch_id(username)}?hard_delete=#{hard_delete_on_api_removal}", where it then needs to fetch the user ID via API, which requires a PAT for the root user.

However, once it got to fabricate! in personal_access_token.rb, Flow::Login.sign_in_unless_signed_in(as: user) only checked whether we were signed in as any user. Because of this, it proceeded to create a PAT for the non-admin user that was still logged in from register_spec.rb, while storing that token for root in the code.

This change will check to see if we are signed in as the current PAT user, and if not, sign in as that user.

How to set up and validate locally

1. Export your GITLAB_INITIAL_ROOT_PASSWORD and QA_GITLAB_URL environment variables in your terminal
2. In register_spec.rb, comment out the while LDAP is enabled describe block
3. Run the following command on your local GDK GITLAB_QA_ADMIN_ACCESS_TOKEN=<any_admin_user_pat_here> bundle exec rspec qa/specs/features/browser_ui/1_manage/login/register_spec.rb qa/specs/features/ee/browser_ui/2_plan/issue_boards/group_issue_boards_spec.rb --order defined
4. Without this change, group_issue_boards_spec.rb will fail with a 403 Forbidden error when trying to fabricate a group. With this change pulled locally, both tests will now pass.

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.