E2E specs for Slack Slash commands integration

Description of the test

This MR introduces specs to test Slack slash commands on Staging ref.

It:

• Uses Chemlab to describe Slack page objects
• Modifies and uses a Chrome profile to remove blocking popup on Slack
• Requires the environment to have a special version of the Slack app configured for the instance - currently this is Staging ref.
• Running locally will authenticate the Slack app test workspace as the QA user (there is no workaround).

Related issue: #374057 (closed)

To run locally, the following env variables are needed. Slack information can be found in the Gitlab-QA 1Password group

• GITLAB_USERNAME (staging ref)
• GITLAB_PASSWORD (staging ref)
• QA_SLACK_EMAIL
• QA_SLACK_PASSWORD
• QA_SLACK_WORKSPACE

# from ./qa
bin/qa Test::Instance::All https://staging-ref.gitlab.com -- qa/specs/features/ee/browser_ui/1_manage/integrations/slash_commands_spec.rb

After merge

We need to add an environment variable to staging ref that overrides GITLAB_QA_USER_AGENT.

After this MR is merged, we can override GITLAB_QA_USER_AGENT to an empty string, and this commit will skip setting the user agent on staging-ref.

Note

The staging ref pipeline will need to be configured to pass through the needed env variables.

Testcases

• https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/377890
• https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/377891
• https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/377892
• https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/377893
• https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/377894

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.