Restricted Thumbnails don't load for any users

[tdonohue]

(Discovered during the review of #1556, but it's not specific to Withdrawn Item thumbnails)

Describe the bug
When a Thumbnail image has any sort of access restrictions, it is unable to display even to EPersons who have those access rights. As a basic example, if you modify a Thumbnail image bitstream to have an Administrator READ policy (without an Anonymous READ policy), then that Thumbnail will no longer be displayed for any users, even Administrators. Any time it is accessed, a 401 response will be sent back by the REST API.

As described in 1556, the issue appears to be that the thumbnail gets rendered (see thumbnail.component) by putting its /content link directly in the template and letting the browser retrieve it. So there is no authorisation or short lived token added.

    <img *ngIf="src !== null" class="thumbnail-content img-fluid"
         [src]="src | dsSafeUrl" [alt]="alt | translate" (error)="errorHandler()">

The solution would be just like for restricted downloads to retrieve a short-lived token first, and add it to the contents url. However this is an image shown/resolved by the browser on item page/search grid view/..., so can't go through a 'download page' like done for (restricted) downloads...

To Reproduce
One basic example:

1. Find an Item which has an existing Thumbnail
2. Edit the Item, find the Thumbnail bitstream and Edit its policies
3. Remove any Anonymous READ policy. Add an Admin READ policy
4. Now, go back to the Item. Verify the Thumbnail doesn't load (your browser's devtools will show a 401 response code)
5. Login as an Admin, verify the Thumbnail still doesn't load.

Expected behavior
Ideally, restricted thumbnails should still be displayed to users who have permissions to view them.

** Workaround **
Currently, the workaround is to ensure all Thumbnails are publicly available. If you encounter this issue, you can modify the policies of the Thumbnail bitstream to ensure it has an Anonymous READ policy.

Related work

• Discovered during review of Withdrawn item tombstone #1556.
• Likely needs to be solved in a way similar to how we managed restricted bitstream downloads in Authorization for downloads of restricted bitstreams #716 and Bitstream download page #1004 (which fixed 924)