Drop support for HEAD requests as auth probes

[tomcrane]

This issue does not address a published spec, but does propose simplifying an approach that has been in drafts of auth (and experimental implementations) for a while.

For an image service, there is an info.json service description endpoint. This acts as the place to attach auth service information, and also acts as a probe service - the client asks for the info.json and observes the HTTP status code of the response.

For AV resources (and, in fact, all content resources) there is no service description document. It's not a service - it's just a binary resource on the web. The current draft of the auth spec introduces a separate probe service, but makes an assumption that this might not always be possible and that the resource itself can act as its own probe service - the client observes the status code of an HTTP request made by script (e.g., fetch) to the resource itself (e.g., an MP4 file). To avoid requesting huge AV files just to see the status code, the draft auth spec says that this direct form of probe should be a HEAD request.

This offers implementation flexibility but it makes the spec more complicated, simply because it has to talk about HEAD requests, and introduce more branches into the flow diagram.

https://preview.iiif.io/api/1290-auth-probe-service/auth/2.0/#21-probe-service

Are there significant AV use cases in particular where it may be possible to implement the HEAD probe but not to implement a separate probe service? If not, this issue suggests dropping the HEAD pattern simply to simplify the possible flows.