Migrate auto-resolve-done-jira-issue and create-jira-issues-for-community-activities to use API Key Manager for Jira (OSOE-726)

[Piedone]

This supersedes #275.

Our auto-resolve-done-jira-issue and create-jira-issues-for-community-activities actions use the now unmaintained gajira* actions, so we need to do something to migrate away from them. Furthermore, they need an Atlassian API token to work, which allows you to do everything the user account corresponding to that token can do. This is a problem, because (until Jira guest users are available, if ever) you need to create a separate (paid) Jira user for every use case if you don't want to expose excessive access to your Jira instance.

The API Key Manager for Jira extension lets you manage more restricted API access, so we should use that:

• Official API Key Manager for Jira docs are here.
• You can contact their support for help here.
• What uses the gajira* actions now should use plain PS HTTP requests. We already do this for adding an issue link to the affected GitHub resource here.
• Most possibly the Login to Jira steps aren't needed at all.
• Document the necessary setup under each workflows' section in the MD file.

Jira issue

[Piedone]

For API Key Manager to be more secure overall than a standard API token created under a user account just for this (with access just to selected projects), we need the following features:

• Wildcard pattern for API key endpoint: for "Post-pull request checks automation", we need to access /rest/api/3/issue/$issueKey/transitions with both POST and GET. Currently, we can only restrict a key to something like /rest/api/3/issue/ADHOC-, which allows the key to do anything in the given project. We can't use /rest/api/3/issue/ADHOC-*/transitions. Similarly, we'd need /rest/api/3/issue/ADHOC-*/remotelink-style patterns to restrict the key that adds GitHub issue (PR, discussion) links to Jira issues as part of "Create Jira issues for community activities".
  • They're working on this and will have it perhaps by the end of the year.
• Ability to restrict a key to create issues only in a single project. For now, /rest/api/3/issue restricted to POST is the only way. However, this allows anybody with the key not just to create issues in any project, but also to update any issue under our Jira.
  • They have this planned but it is still some time away.
• Ability to have multiple endpoint-method pairs for a single key, not to have to maintain many keys, and ask our users to do the same. Currently, we need to have 3 separate keys for our use case, to be able to:
  • Transition issues in a given project (/rest/api/3/issue/- POST and GET).
  • Create issues in a given project and add remote links to them (/rest/api/3/issue POST; would like in a given project but this allows more).
  • /rest/api/3/serverInfo GET to be able to fetch the server’s public base URL, in order to build the user-facing URL of an issue.
  • They're evaluating how big of a LOE this would be.
• Ideally, it would also be possible to restrict all issue updates to issues created via a given API key too, but this is less of an issue.

[Piedone]

Updates from the developers:

• Wildcard pattern for API key endpoint: "Wildcards are currently in testing, hopefully we’ll be able to release this by the end of the months."
• Ability to restrict a key to create issues only in a single project: "Our current take is to add a specialized type of key that could only be used for issue creation and only for a specific project – which would be much easier to enforce. Even though, it’ll be a long time before that can become a feature – think many months." I'll have a follow-up question here, but I suspect this means that if we want to allow any issue write scenario, then API Key Manager will open up access to our Jira even more than the built-in API keys. This makes it completely unsuitable for us, since every use case of ours involves creating issues, and we want more restriction compared to the out of the box API keys, not less.
• Ability to have multiple endpoint-method pairs for a single key: "This is still on the wishlist, but has been pushed further down for now. Technically, it is not too much of an issue, but it’ll take time to make the UI feel right." Without this, we'd need to use two API keys for create-jira-issues-for-community-activities, or keep the JIRA_BASE_URL parameter.
• Restrict all issue updates to issues created via a given API key: not coming anytime soon.

"Ability to restrict a key to create issues only in a single project" is a deal breaker for us.

[Piedone]

Re #2 above, yes, this is the case. Thus, we can't use API Key Manager. We thus need to table this and get back to #275.