Add support for content range requests when getting blobs

OCI artifacts support has landed in various OCI specs v1.1.0 which
allows for arbitrary artifact types, small and large.

Large artifacts (even existing container images) pose a particular
challenge that:

1) it takes too long to download
2) it takes too long to unpack

This PR begins to address 1) above.

The client can initiate a HEAD request to get the size and later
multiple GET range requests to download a blob in parallel.

Signed-off-by: Ramkumar Chinchani <[email protected]>

Author: Ramkumar Chinchani

spec.md

@@ -190,6 +190,11 @@ If present, the value of this header MUST be a digest matching that of the respo
 
 If the blob is not found in the registry, the response code MUST be `404 Not Found`.
 
+A GET request MAY also include a `Range` request header to download part of a
+blob in accordance with [RFC 9110](https://datatracker.ietf.org/doc/html/rfc9110#name-range-requests).
+The response code SHOULD either be `216 (Partial Content)` or `416 (Range Not Satisfiable)`
+in case of an invalid range. A registry MAY ignore the `Range` header or respond with `Accept-Ranges: none`.
+
 ##### Checking if content exists in the registry
 
 In order to verify that a repository contains a given manifest or blob, make a `HEAD` request to a URL in the following form: