Draft: [API] Add merge request endpoint for mentioned issues not closing

What does this MR do?

This MR will add a new endpoint for project MRs, similar to https://docs.gitlab.com/ee/api/merge_requests.html#list-issues-that-close-on-merge, that will list any referenced issues that won't close when the MR is merged. This relates to a need that I encountered in https://gitlab.com/gitlab-org/gitlab-triage/-/merge_requests/195, for triaging MRs that don't reference an issue, as the relationship is only accessible from Issue->MR, and not from MR->Issue

The endpoint is accessible at /api/v4/projects/:id/merge_requests/:merge_request_iid/issues_mentioned_but_not_closing

Questions / Concerns

• Should these relationships be cached in the same way that visible_closing_issues_for calls cache_merge_request_closes_issues, and stores the results in a model?

  I didn't feel that it was needed, as closes_issues is scanning not only the title and description of the MR, but also all of the commit messages. The cached results are being used by multiple services related to merge requests (post merge, reopen, etc), in addition to the merge request presenter and API that issues_mentioned_but_not_closing (and now visible_issues_mentioned_but_not_closing_for) is used by.

• Should tests be added?

  I began adding tests for visible_issues_mentioned_but_not_closing_for, until I realized that it is already covered by tests for issues_mentioned_but_not_closing and strong_memoize, and the value from a specific test would be extremely minimal, and there don't appear to be specs for the API endpoints (since those are covered by model specs).

Screenshots (strongly suggested)

/api/v4/projects/:id/merge_requests/:merge_request_iid/closes_issues

`

/api/v4/projects/:id/merge_requests/:merge_request_iid/issues_mentioned_but_not_closing

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team