Handling multiple active issue trackers
## Problem Currently, it is possible to enable multiple issue trackers in GitLab in addition to GitLab issues. For example, a customer can have Jira issues or PivotalTracker enabled in addition to GitLab issues. Some organizations may require the ability to use multiple issue trackers, however we should set better defaults in order to discourage these types of productivity anti-patterns. This is not limited to issue trackers, considering external wikis, etc. There also isn't a consistent behavior for how the system handles multiple issue trackers. For example, a customer can enable Jira issues in addition to GitLab issues, but cannot enable Jira issues and Asana (2 external issue trackers). ## Proposal (high-level) 1. When enabling a new tracker, communicate whether or not another tracker is already active https://gitlab.com/gitlab-org/gitlab/-/issues/328470 1. If choosing to enable an additional tracker, proactively offer to disable the prior tracker https://gitlab.com/gitlab-org/gitlab/-/issues/328606 1. Once a new tracker has been enabled, communicate where the new tracker can be leveraged in GitLab. For example, [creating a new Jira issue from an unresolved merge request](https://gitlab.com/gitlab-org/gitlab/-/issues/249579). <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
epic