Add e2e spec for GitLab as an OAuth provider

Description of the test

Adds an e2e test that creates a GitLab OAuth Application and uses it to login to GitLab.

The test is similar to the one added in this MR for GitLab as an OIDC provider. This MR also refactors that test to use shared_examples.

Related issue: gitlab-org/quality/testcases#3982 (closed)

How to set up and validate locally

1. Make sure your GDK is set to run on a non-localhost address such as gdk.test:3000.
2. Configure a loopback interface 172.16.123.1
3. Make sure Docker desktop or Rancher desktop is running.
4. Add an entry for gitlab-oauth-consumer.bridge pointing to 127.0.0.1 to your /etc/hosts file. If you are planning to run the entire spec file, you will also need to add a similar entry for gitlab-oidc-consumer.bridge.
5. From the qa directory:

bundle install

RELEASE_REGISTRY_URL='registry.gitlab.com' RELEASE_REGISTRY_USERNAME='<your_gitlab_username>' RELEASE_REGISTRY_PASSWORD='<your_gitlab_personal_access_token>' RELEASE='registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:c0ae46db6b31ea231b2de88961cd687acf634179' GITLAB_QA_ADMIN_ACCESS_TOKEN="<your_gdk_admin_personal_access_token>" QA_DEBUG=true CHROME_HEADLESS=false bundle exec bin/qa Test::Instance::All http://gdk.test:3000 qa/specs/features/browser_ui/1_manage/login/login_via_oauth_and_oidc_with_gitlab_as_idp_spec.rb:151

How to set up and validate locally

Checklist

• Confirm the test has a testcase: tag linking to an existing test case in the test case project.
• Note if the test is intended to run in specific scenarios. If a scenario is new, add a link to the MR that adds the new scenario.
• Follow the end-to-end tests style guide and best practices.
• Use the appropriate RSpec metadata tag(s).
• Most resources will be cleaned up via the general cleanup task. Check that is successful, or ensure resources are cleaned up in the test:
  • New resources have api_get_path and api_delete_path implemented if possible.
  • If any resource cannot be deleted in the general delete task, make sure it is ignored.
  • If any resource cannot be deleted in the general delete task, remove it in the test (e.g., in an after block).
• Ensure that no transient bugs are hidden accidentally due to the usage of waits and reloads.
• Verify the tags to ensure it runs on the desired test environments.
• If this MR has a dependency on another MR, such as a GitLab QA MR, specify the order in which the MRs should be merged.
• (If applicable) Create a follow-up issue to document the special setup necessary to run the test: ISSUE_LINK
• If the test requires an admin's personal access token, ensure that the test passes on your local environment with and without the GITLAB_QA_ADMIN_ACCESS_TOKEN provided.