Manual backlog grooming and prioritization

gitlab-ee~9594407 since I (VictorW) and other product members have said they would use this for grooming their respective backlogs.

---

Designs for the problem in &482 (closed):

Problem

• Currently, it is very difficult (if not impossible) to order a large list of issues, to indicate priority and/or order of implementation.
• This is necessary for typical Agile use cases, such as grooming a backlog of issues, that are currently not scoped into any sprint yet.
• Currently in GitLab, we have priority labels. This is not a scalable solution, since you cannot label every single issue with a priority label. Furthermore, is very difficult to re-order issues quickly/easily using labels.
• We have a priority / priority label sort for issues lists, but they suffer the problem above, since they are based on priority labels.
• You can order issues within an issue board, but the space is very limiting. Even if you use the Open list, it is very difficult to see a large list of issues. To mitigate the problem, you can narrow down the issues to a small subset, but that defeats the purpose of backlog grooming, where you want a large set of issues visible, that you can continuously groom over time.

Solution

• Make group issues and project issues lists support manual reordering, exactly like how you re-order issues in a board.
• In particular, there is a new dropdown selection called Manual ordering. If you select that mode, then you can drag and drop issues in the list view.
• The order is saved to the system. The relative ordering, for any two given issues in the instance, is stored and saved and used for all issue lists views, and all board views. That means that if you re-order in one place, then it is reflected everywhere else in the instance. In other words, board lists are inherently always use the Manual ordering option. And there is no other option.
• The order is shared in epic lists to be consistent. I.e. if you make an ordering re-arrangement in an epic list, it is reflected elsewhere as well.
• It will be difficult to groom a large backlog, especially if the list page only shows 20 issues per paginated page. To solve this, we need to do infinite scrolling and/or have some way to move an issue from one paginated page to another page easily.
• If you create a new issue while in this mode, then the issue would show all the way at the end.
• You should probably be able to re-order issues in the closed and all tabs too.

Proposal

• Add Manual option in sort dropdown
• List displays 100 issues at a time
• Issues use new drag-and-drop style (similar to issue boards)
• Users can drag issues anywhere on the list, at any time. The list is automatically saved in the current order.

Note- I opened an MR for the manual order styles (https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9278/diffs). To whoever picks this up you can add .manual-ordering to .issues-holder to get it to work