Allow Jira DVCS integration with read_api scope

Release notes

OAuth2 connections used for the Jira DVCS connector can use an application scope of read_api rather than api if the ability to modify the state of the GitLab instance from Jira is not required or desired. In particular, the use of read_api instead of api will prevent the creation of merge requests from the JIRA interface.

Problem to solve

Under the principal of least permissions, the permissions provided for a particular task should be scoped to align with those required for task completion. In the case of the Jira DVCS connector, an application with an api scope is required to configure the OAuth2 connection. However, the majority of the Jira DVCS functionality only queries the GitLab instance and doesn't permute the instance state. If it is considered acceptable to forego the functionality which permutes the instance state (possibly just the ability to create MRs from JIRA), the read_api scope would be a more appropriate scope than api from a principal of least permissions.

Proposal

Without knowing the details of how permissions checks within GitLab are performed, it is assumed that an access key with the api permission would pass a security check which requires the access key to possess the read_api permission. Given this assumption, the requisite change would be to review the GitLab subsystem used to provide the DVCS endpoint and ensure that the security checks use a read_api scope for those operations that query the state of the instance and only use the api scope for those operations that mutate the state instance.