Call QuickActionsService on Note update

Add support for notes which just contain
commands after editing

Return http status gone (410) if note was deleted

Temporary frontend addition so it is not
failing when a note is deleted

Move specs to shared examples

Fix rubocop style issue

Deleting note on frontend when status is 410

Use guard clause for note which got deleted

Simplified condition for nil note

This method should no longer be called
with nil note

Refactoring of execute method to reduce
complexity

Move errors update to delete_note method

Note is now deleted visually when it only
contains commands after update

Add expectation

Fix style issues

Changing action to fix tests

Add tests for removeNote and update
deleteNote expectations

Remove project from NotesFinder constructor

Add project parameter to specs

Also look for methods in private scope

Fix specs to match new NotesFinder constructor

In the Snippets::NotesController the noteable was resolved and
authorized through the :snippet_id, so by passing a :target_id for a
different snippet it was possible to create a note on a snippet
where the user would be unauthorized to do so otherwise.

This fixes the problem by ignoring the :target_id and :target_type from
the request, and using the same noteable for creation and authorization.

When executing quick actions, this limits the `commands_changes`
response to only those used by the frontend

Removes unneeded params from permitted list

This also fixes commenting on commits with a hash starting with a large
number

[master]Fixed ability to comment on and edit/delete comments on locked or confidential issues

See merge request gitlab/gitlabhq!2612

Enables frozen string for the following:

* app/controllers/*.rb
* app/controllers/admin/**/*.rb
* app/controllers/boards/**/*.rb
* app/controllers/ci/**/*.rb
* app/controllers/concerns/**/*.rb

Partially addresses #47424.

The status is shown for
- The author of a commit when viewing a commit
- Notes on a commit (regular/diff)
- The user that triggered a pipeline when viewing a pipeline
- The author of a merge request when viewing a merge request
- The author of notes on a merge request (regular/diff)
- The author of an issue when viewing an issue
- The author of notes on an issue
- The author of a snippet when viewing a snippet
- The author of notes on a snippet
- A user's profile page
- The list of members of a group/user

This refactors the Markdown pipeline so it supports the rendering of
multiple documents that may belong to different projects. An example of
where this happens is when displaying the event feed of a group. In this
case we retrieve events for all projects in the group. Previously we
would group events per project and render these chunks separately, but
this would result in many SQL queries being executed. By extending the
Markdown pipeline to support this out of the box we can drastically
reduce the number of SQL queries.

To achieve this we introduce a new object to the pipeline:
Banzai::RenderContext. This object simply wraps two other objects: an
optional Project instance, and an optional User instance. On its own
this wouldn't be very helpful, but a RenderContext can also be used to
associate HTML documents with specific Project instances. This work is
done in Banzai::ObjectRenderer and allows us to reuse as many queries
(and results) as possible.

And use .rubocop.yml to exclude paths we don't care,
rather than using the cop itself to exclude.

Added discussion_line_code value to note response and use it to query the right row for the discussion UI

Reduces the number of queries needed to redact notes to which
the user does not have access. Also includes an N+1 query test
as a guard against future issues.

This is a follow-up from https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14327#note_40976854.

A commit comment shows in the MR, but if the MR is from a fork, it will have a
different project ID to the MR's target project. In that case, add an
note_project_id param so that we can pick the correct project for the note.