Previously submitting a DELETE request to an issuable URL would be
enough to destroy it, but this should require human confirmation.  We
now require that the `destroy_confirm` parameter is set to a truthy
value before this can complete.

In addition, we log a Sentry error if a deletion arrived without
confirmation.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/62387

Send a `persist_filter: false` param to backend when
opening links to notes and auto-switching to show
all notes

Remove project from NotesFinder constructor

Add project parameter to specs

Also look for methods in private scope

Fix specs to match new NotesFinder constructor

This reverts merge request !29733

Add spec for concern IssuableActions

Add shared samples for discussions endpoint

Add schema validations for discussions

Fix rubocop style issue

Make target assignable

Use new possibility to provide target

This is a port MR for CE

Original MR:

https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14141

Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161
(code out of ee/ folder).

Scoped labels in EE require additional changes in CE code.

Also removes specs related to the flag

receive data on when there is a conflict

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.

This whitelists all existing offenses for the various CodeReuse cops, of
which most are triggered by the CodeReuse/ActiveRecord cop.

For issuable models we keep two timestamps:
updated_at which is updated whenever any model attribute is changed,
last_edited_at which is changed when only title or description is
changed.

In UI bellow description we display who and when updated the item. But
last_edited_by (used for 'who') is mistakenly combined with updated_at
(when), last_edited_at should be used instead.

Closes #41247

When the target is deleted, todos are destroyed, but we did not reset the todo
cache for users with todos on the deleted target. This would only update after
the next time the todo cache was updated for that user.