E2E - Root cause analysis with Duo Chat

Description of the test

New E2E test for Root Cause Analysis with Duo Chat. When feature flags :root_cause_analysis_duo and :ai_build_failure_cause are enabled, user can get a failure analysis from Duo Chat by clicking Troubleshoot button on a failed job's details page.

Test case https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/472130

Relates to https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/issues/2410 , #471617 (closed)

How to set up and validate locally

This test only runs against Staging and Staging-canary for now since the feature only work on SAAS instance and is still behind feature flags.

From the qa directory:

bundle install
export WEBDRIVER_HEADLESS=false # If you'd like to watch the test in action

GITLAB_ADMIN_USERNAME="gitlab-qa-bot" GITLAB_ADMIN_PASSWORD=<password> GITLAB_QA_ADMIN_ACCESS_TOKEN=<token>  GITLAB_QA_USER_AGENT=<agent_token> QA_GITLAB_URL=https://staging.gitlab.com bundle exec rspec qa/specs/features/ee/browser_ui/16_ai_powered/duo_chat/root_cause_analysis_with_duo_chat_spec.rb

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.