Fixes #4010 Remote Images for API Integrations

[tadean]

This draft PR provides a mechanism for using remote images for API integrations, via remote stream wrappers. This means that the original image is not stored locally, and instead fetched as needed, with only computed image derivatives for styles being actually stored on the site.

This was part of a proof of concept investigation about whether we should potentially try to avoid fetching local copies of external images; the alternative to this approach is fetching each external image via queued download and also periodically needing to determine if the local image and the remote image match and remain in sync.

Presently this functionality of creating the remote image takes place in an event subscriber; before this PR leaves draft status it should be converted to a process plugin.

Todo:

• Move functionality to process plugin
• Trellis event images

Note: in testing, one potential issue I've noticed with this approach is that Trellis event image URLs are extremely lengthy. We would need a solution for URLs which are too long for the uri path in the files managed table.

Related issues

#4010

How to test

• enable az_http and az_person_profiles_import
• login
• visit /admin/config/az-quickstart/settings/az-person-profiles-import
• enter your profiles API token
• visit /admin/content/profiles/import
• import several NetIDs of faculty which have profile photos in the Profiles site
• view imported people
• Verify that the images work
• Verify that /admin/content/files contains links to the original photo, off-site
• Verify that computed image derivatives on content pages contain links to on-site URLs with a folder structure that mimics the url

Types of changes

Arizona Quickstart (install profile, custom modules, custom theme)

• Patch release changes
  • Bug fix
  • Accessibility, performance, or security improvement
  • Critical institutional link or brand change
  • Adding experimental module
  • Update experimental module
• Minor release changes
  • New feature
  • Breaking or visual change to existing behavior
  • Upgrade experimental module to stable
  • Enable existing module by default or database update
  • Non-critical brand change
  • New internal API or API improvement with backwards compatibility
  • Risky or disruptive cleanup to comply with coding standards
  • High-risk or disruptive change (requires upgrade path, risks regression, etc.)
• Other or unknown
  • Other or unknown

Drupal core

• Patch release changes
  • Security update
  • Patch level release (non-security bug-fix release)
  • Patch removal that's no longer necessary
• Minor release changes
  • Major or minor level update
• Other or unknown
  • Other or unknown

Drupal contrib projects

• Patch release changes
  • Security update
  • Patch or minor level update
  • Add new module
  • Patch removal that's no longer necessary
• Minor release changes
  • Major level update
• Other or unknown
  • Other or unknown

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My change requires release notes.

[trackleft]

We could use this for remote publication PDFs as well