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

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

Fix typos on sorting dropdown related to due date
Remove constant array and add Structs on Issue to keep due date data to fill options

Add due_date text field to sidebar issue#show
Add ability sorting issues by due date ASC and DESC
Add ability to filtering issues by No Due Date, Any Due Date, Due to tomorrow, Due in this week options
Add handling issue due_date field for MergeRequest
Update CHANGELOG
Fix ambigous match for issues#show sidebar
Fix SCREAMING_SNAKE_CASE offenses for due date contants
Add specs for due date sorting and filtering on issues

  This problem only was affecting the dev env.

The `non_archived` scope applied here
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/controllers/conc
erns/issues_action.rb#L5 overrides the previous `ORDER BY` applied
inside the IssuesFinder, with the default scope of the Project model,
resulting in SQL errors.

According to endbosses' suggestions.

1. Make the "subscribed" text in Issuable sidebar reflect the labels
   subscription status

2. Current user mut be logged-in to toggle issue/MR/label subscription

1. Allow subscribing (the current user) to a label

- Refactor the `Subscription` coffeescript class
  - The main change is that it accepts a container, and conducts all
    DOM queries within its scope. We need this because the labels
    page has multiple instances of `Subscription` on the same page.

2. Creating an issue or MR with labels notifies users subscribed to those labels

- Label `has_many` subscribers through subscriptions.

3. Adding a label to an issue or MR notifies users subscribed to those labels

- This only applies to subscribers of the label that has just been
  added, not all labels for the issue.

Make methods return ActiveRecord Relations instead of Arrays.

Closes #9014

The only difference with #9014 is that I thoughed the author should also be
able to assign the issue. If this is unwanted behavior Ill revert it.

1. We now display the index of the current issuable among all its project's
issuables, of the same type and with the same state.
2. Also, refactored a bit the Issuable helpers into a new IssuablesHelper
module.
3. Added acceptance specs for the sidebar counter.

- Add `avatar_url`, `description`, `git_ssh_url`, `git_http_url`,
  `path_with_namespace` and `default_branch` in `project` in push, issue,
  merge-request and note webhooks data
- Deprecate the `ssh_url` in favor of `git_ssh_url` and `http_url` in
  favor of `git_http_url` in `project` for push, issue, merge-request and
  note webhooks data
- Deprecate the `repository` key in push, issue, merge-request and
  note webhooks data, use `project` instead

Everytime the User check or uncheck a Task Item from the Issue or
Merge Request description, a new update is going to be
added to the activity logs of the Issue or Merge Request.

Note that when using the edit form, you can only update the Task item
status or add/delete/modify existing ones. Doing both actions is not
fully supported.

When using IssuableFinder/IssuesFinder to find issues for multiple
projects it's more efficient to use a JOIN + a "WHERE project_id IN"
condition opposed to running a sub-query.

This change means that when finding issues without labels we're now
using the following SQL:

    SELECT issues.*
    FROM issues
    JOIN projects ON projects.id = issues.project_id

    LEFT JOIN label_links ON label_links.target_type = 'Issue'
                          AND label_links.target_id  = issues.id

    WHERE (
        projects.id IN (...)
        OR projects.visibility_level IN (20, 10)
    )
    AND issues.state IN ('opened','reopened')
    AND label_links.id IS NULL
    ORDER BY issues.id DESC;

instead of:

    SELECT issues.*
    FROM issues
    LEFT JOIN label_links ON label_links.target_type = 'Issue'
                          AND label_links.target_id  = issues.id

    WHERE issues.project_id IN (
        SELECT id
        FROM projects
        WHERE id IN (...)
        OR visibility_level IN (20,10)
    )
    AND issues.state IN ('opened','reopened')
    AND label_links.id IS NULL
    ORDER BY issues.id DESC;

The big benefit here is that in the last case PostgreSQL can't properly
use all available indexes. In particular it ends up performing a
sequence scan on the "label_links" table (processing around 290 000
rows). The new query is roughly 2x as fast as the old query.

These scopes can just sort by the "id" column in descending order to
achieve the same result. An added benefit is being able to perform a
backwards index scan (depending on the rest of the final query) instead
of having to actually sort data.

This ensures we don't end up running N+1 queries for the objects in the
affected collections.