Add BlocksJsonSerialization model concern and include it in User

Closes #37947

See merge request gitlab-org/gitlab-ce!14350

Previously, this would include the entire User record in the update
hash, which was rendered in the response using `to_json`, erroneously
exposing every attribute of that record, including their (now removed)
private token.

Now we only include the user ID, and perform the lookup on-demand.

If Unlinking a fork would fail somewhere after this, the LFS objects
might still be linked. Which would cause issues when trying to destroy
a project.

Resolve "Todo notification count shows notification without having a todo"

Closes #40871

See merge request gitlab-org/gitlab-ce!15807

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.

* upstream/master: (671 commits)
  Make rubocop happy
  Use guard clause
  Improve language
  Prettify
  Use temp branch
  Pass info about who started the job and which job triggered it
  Docs: add indexes for monitoring and performance monitoring
  clearer-documentation-on-inline-diffs
  Add docs for commit diff discussion in merge requests
  sorting for tags api
  Clear BatchLoader after each spec to prevent holding onto records longer than necessary
  Include project in BatchLoader key to prevent returning blobs for the wrong project
  moved lfs_blob_ids method into ExtractsPath module
  Converted JS modules into exported modules
  spec fixes
  Bump gitlab-shell version to 5.10.3
  Clear caches before updating MR diffs
  Use new Ruby version 2.4 in GitLab QA images
  moved lfs blob fetch from extractspath file
  Update GitLab QA dependencies
  ...

Prevent worker that updates merge requests head pipeline from failing jobs

Closes #41021

See merge request gitlab-org/gitlab-ce!15870

Execute quick actions when creating MR from issue

Closes gitlab-ee#4277

See merge request gitlab-org/gitlab-ce!15810

In CE, this does nothing - the `MergeRequests::BuildService` will, at the time
of writing, never return a description for this case.

In EE, a project can have a default MR template, which will be returned by the
service. Previously we were only using the description passed in the params,
ignoring any already set on the object. Now we fall back to the one set on the
object if there was none in the params, allowing quick actions to be executed
from default MR templates when creating an MR from an issue.