When reading conflicts:
1. Add a `type` field. `text` works as before, and has `sections`;
`text-editor` is a file with ambiguous conflict markers that can only
be resolved in an editor.
2. Add a `content_path` field pointing to a JSON representation of the
file's content for a single file.
3. Hitting `content_path` returns a similar datastructure to the `file`,
but without the `content_path` and `sections` fields, and with a
`content` field containing the full contents of the file (with
conflict markers).
When writing conflicts:
1. Instead of `sections` being at the top level, they are now in a
`files` array. This matches the read format better.
2. The `files` array contains file hashes, each of which must contain:
a. `new_path`
b. `old_path`
c. EITHER `sections` (which works as before) or `content` (with the
full content of the resolved file).
Ability to bulk assign issues to author of merge request
## What does this MR do?
Provides a link to auto-assign issues to the author of a merge request, when they are mentioned as being closed by the MR.
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
To help avoid working on a MR without having assigned related issues to self
## What are the relevant issue numbers?
Fixes#18876
## Screenshots (if relevant)
## Tasks
- [x] Refactor or move away from using `BulkUpdateService`
- [x] ~~Consider alternate link message when only a subset of issues will be assigned~~
- [x] Minimize repeated calls to expensive `closes_issues` method
- [x] Move away from using inflector for pluralization and fix flash message
- [x] Change auth `before_action` and fallback to error flash message
- [x] Shouldn't overwrite current assignee if one exists
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] ~~[Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~
- [x] ~~API support added~~
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !5725
Allow browsing branches that end with '.atom'
## What does this MR do?
1. Simplify the regex capture in the routing for the CommitsController
to not exclude the '.atom' suffix. That's a perfectly valid git
branch name, so we shouldn't blow up if we get it.
2. Because Rails now can't automatically detect the request format, add
some code to do so in `ExtractPath` when there is no path. This means
that, given branches 'foo' and 'foo.atom', the Atom feed for the
former is unroutable. To fix this: don't do that! Give the branches
different names!
## Why was this MR needed?
Creating a branch or tag name ending in '.atom' would cause some 500s on that repo.
## What are the relevant issue numbers?
Closes#21955. Related to !5994.
See merge request !6750
We need to do two things to support this:
1. Simplify the regex capture in the routing for the CommitsController
to not exclude the '.atom' suffix. That's a perfectly valid git
branch name, so we shouldn't blow up if we get it.
2. Because Rails now can't automatically detect the request format, add
some code to do so in `ExtractPath` when there is no path. This means
that, given branches 'foo' and 'foo.atom', the Atom feed for the
former is unroutable. To fix this: don't do that! Give the branches
different names!
Issue boards new issue form
## What does this MR do?
Adds a new issue form into the issue boards lists.
## Screenshots (if relevant)
## What are the relevant issue numbers?
Part of #21219
See merge request !6653
