CE port of https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/962

Notice that this param is being supported since V3, but we have not added the proper docs for it

Closes #29631

Signed-off-by: NRémy Coutable <remy@rymai.me>

merge_request_for_resolving_discussions ->
merge_request_to_resolve_discussions_of

And deduplicate the finding of MR's & discussions. Now the searching
is done in the service, istead of the controller & the API.

Delegate a discussion in a merge request into a new issue.
The discussion wil be marked as resolved and a system note will be
added linking to the newly created issue.

- As opposed to the issue `id` that was previously being used.
- This brings the API routes closer to the web interface's routes.
- This is specific to API v4.

This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.

New endpoints are:

POST :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/time_estimate"

POST :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/reset_time_estimate"

POST :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/add_spent_time"

POST :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/reset_spent_time"

GET  :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/time_stats"

- Use IssuesFinder for the /issues API resouce
- Tests for iid filter in project issues API resource
- Tests for No Milestone filter in issues API resources
  The "No Milestone" case was not previously tested, and the `/issues`
  resource did not support the the `milestone` parameter.
- Return issues where all labels match from the issues and project issues
  API resources, like the group issues resource already does. See
  https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6825#note_17474533Signed-off-by: NRémy Coutable <remy@rymai.me>

Current filtering for "/projects/:id/issues" endpoint
returns no results for "No Milestone" query.

This PR introduces fix by copying filtering from "/groups/:id/issues"
which works as expected.

Following a discussion in !7180

When a merge request can only be merged when all discussions are
resolved. This feature allows to easily delegate those discussions to a
new issue, while marking them as resolved in the merge request.

The user is presented with a new issue, prepared with mentions of all
unresolved discussions, including the first unresolved note of the
discussion, time and link to the note.

When the issue is created, the discussions in the merge request will get
a system note directing the user to the newly created issue.

Replace issue access checks with use of IssuableFinder

Split from !2024 to partially solve https://gitlab.com/gitlab-org/gitlab-ce/issues/23867

## Which fixes are in this MR?

⚠ - Potentially untested  
💣 - No test coverage  
🚥 - Test coverage of some sort exists (a test failed when error raised)  
🚦 - Test coverage of return value (a test failed when nil used)  
✅ - Permissions check tested

### Issue lookup with access check

Using `visible_to_user` likely makes these security issues too. See [Code smells](#code-smells).

- [x] 🚦 app/finders/notes_finder.rb:15 [`visible_to_user`]
- [x] 🚥 app/views/layouts/nav/_project.html.haml:73 [`visible_to_user`] [`.count`]
- [x] ✅ app/services/merge_requests/build_service.rb:84 [`issue.try(:confidential?)`]
- [x] ✅ lib/api/issues.rb:112 [`visible_to_user`]
  - CHANGELOG: Prevented API returning issues set to 'Only team members' to everyone
- [x] ✅ lib/api/helpers.rb:126 [`can?(current_user, :read_issue, issue)`] Maybe here too?
- [x] ✅ lib/gitlab/search_results.rb:53 [`visible_to_user`]

### Previous discussions
- [ ] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#b2ff264eddf9819d7693c14ae213d941494fe2b3_128_126
- [ ] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#7b6375270d22f880bdcb085e47b519b426a5c6c7_87_87

See merge request !2031

Fix label creation non members

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/23416

See merge request !2006

Signed-off-by: NRémy Coutable <remy@rymai.me>

adds test to check whether or not an email is sent to label subscribers after creating a new issue through the api