Image field default value not shown when upload destination set to private file storage

Problem/Motivation

In an image field's configuration, you can specify a default image to be displayed as a fallback if the content editor does not upload an image to that field.

When an image field's Upload Destination is set to the Private file storage destination (i.e.: the private:// stream), attempting to view (i.e.: download) the default image returns an HTTP 403 Access Denied, resulting in a broken image on the page.

Steps to reproduce

1. Add an image field to a content entity type. In the new image field's Field Settings, set its Upload destination to Private files. In its settings, upload a default image.
2. Add an image field to a content entity type. In the new image field's Field Settings, set its Upload destination to Public files. In its settings, upload a default image.
3. Create a new instance of that content entity. Leave both image fields empty.
   • Expected behavior: The default image for both fields are shown,
   • Actual behavior: The default image for the field whose Upload Destination is set to "Public files" is shown. The default image for the field whose Upload Destination is set to "Private files" is broken.

Inspection in the browser's Network Console shows Drupal responds to the browser's request with an HTTP/403 Access Denied response. Further inspection of the cause of the 403 shows that a \Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException is thrown from \Drupal\image\Controller\ImageStyleDownloadController::deliver() because $this->moduleHandler()->invokeAll('file_download', [$image_uri]) fails to return any headers (i.e.: indicating access denied). In particular, the image module's implementation of hook_file_download() (i.e.: image_file_download()) does not handle a case for default images.

As of 2020-05-29, this happens on 9.1.x and 8.8.x.

Proposed resolution

Modify image_file_download() to handle the case for default images, by granting access if the image URI that is being requested happens to be the default image for at least one field that the current user has 'view' access to.

Remaining tasks

1. Update issue metadata, summary
2. Re-roll patch from #24>
3. Review and feedback - in particular, is the access check that we are making sound and complete?
4. RTBC
5. Maintainer review, feedback
6. Commit
7. Backport?

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

To be determined.

Original report by claudiu.cristea

On an image field where the uploaded destination is set to private:// stream, the default image is returning 403.

If you encounter a WSOD while manually testing, see #2799837: WSOD when changing uri_scheme and setting a new default image at the same time for an image field..