Use Content-Type header from oEmbed thumbnail GET request when determining the file extension

Problem/Motivation

When downloading the thumbnail for an oEmbed resource, the media system needs to figure out what the thumbnail's file extension will be, so that it (the thumbnail) can be used by the image system.

Most of the time, the file extension is right there in the thumbnail URL. But other times, the thumbnail URL has no file extension. In such a case, we make a HEAD request to the thumbnail URL and try to use the Content-Type header it gives us, if any, to determine a file extension. That, however, has two drawbacks:

1. Downloading the thumbnail can result in two HTTP requests (one HEAD and one GET), rather than just one.
2. Some providers, like TikTok, block HEAD requests. This results in the downloaded thumbnail having no file extension, and therefore being unusable by the image system.

Steps to reproduce

You'll need custom code, but create a media source plugin that extends the oEmbed source, and supports TikTok as a provider. You'll see that any media you add with that source will not get a proper thumbnail, since the thumbnail URLs don't have a file extension, and TikTok blocks HEAD requests. This was revealed by #3225184: oEmbed system cannot retrieve thumbnail extensions from TikTok / Vimeo.

(A test module was written for this; see #2.)

Proposed resolution

I think we can kill both of the aforementioned birds with one stone.

If we can't tease the thumbnail file extension out from the thumbnail URL, let's examine the Content-Type header in the GET response (that actually downloads the thumbnail) and derive a file extension that way. Not only will this be more likely to succeed, but it completely removes any need to make a HEAD request.

Remaining tasks

Implement it with test coverage.

User interface changes

None.

API changes

TBD, but an existing protected method may receive a new parameter and/or a deprecation notice.

Data model changes

None.

Release notes snippet

TBD