Add product analytics onboarding E2E spec

Description of the test

Add a test for Product Analytics onboarding.

The test can only run on Staging environment as it requires Product Analytics infra to be setup and Admin privileges.

Short test description:

• Activate Product Analytics for a Project -> Send event -> Verify Product analytics is activated by checking that dashboards are loaded and have data.

How to set up and validate locally

Run this test locally on GDK

• GDK is up and running
• Setup Product Analytics devkit as described in README here - https://gitlab.com/gitlab-org/analytics-section/product-analytics/devkit
• Connect devkit to GKD - https://gitlab.com/gitlab-org/analytics-section/product-analytics/devkit#connecting-gdk-to-your-devkit
• Remove only: { subdomain: :staging } tag from the spec
• Run the test

bundle exec rspec qa/specs/features/ee/browser_ui/8_monitor/product_analytics/onboarding_spec.rb 

Run this test locally against Staging

Note: For the test to work on Staging at the moment the sandbox group gitlab-qa-product-analytics need to be pre-created and set to Ultimate. This is because data-testid for plan badge when no plan is set is only added within this MR. Hence if it's a new group without plan set then the check return unless Page::Admin::Overview::Groups::Show.perform(&:get_group_plan) != 'Ultimate' will fail to find element. (This is not relevant anymore as testid for plan content was deployed to Staging)

• Set needed env variables
  • GITLAB_QA_USER_AGENT
  • GITLAB_QA_ACCESS_TOKEN
  • GITLAB_ADMIN_USERNAME
  • GITLAB_ADMIN_PASSWORD
• Run the test against staging:

QA_GITLAB_URL=https://staging.gitlab.com bundle exec rspec qa/specs/features/ee/browser_ui/8_monitor/product_analytics/onboarding_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.