Allow for automatic content discovery for cross-mounting blobs

When uploading to multiple registries, the user may or may not what
other repositories exist in these registries. Therefore, a client may
perform an unnecessary upload when the registry already has a given
blob. This an optimization that allows the registry to perform the
authz check and check if it can find the blob with a given the passed
digest in its blobstore. If that blob is accessible (from an authz
perspective) to the user, it can then perform the mount automatically
on its behalf.

Because there is a potential a timing attack that could be used to
disclose knowledge of whether or not the registry has a given blob
(for example, a vulnerable version of a Linux image), this an
optional feature for registries to implement.

Signed-off-by: Sargun Dhillon <sargun@sargun.me>

spec.md

@@ -353,7 +353,7 @@ Here, `<blob-location>` is a pullable blob URL.
 
 ##### Mounting a blob from another repository
 
-If a necessary blob exists already in another repository, it can be mounted into a different repository via a `POST`
+If a necessary blob exists already in another repository within the same registry, it can be mounted into a different repository via a `POST`
 request in the following format:
 
 `/v2/<name>/blobs/uploads/?mount=<digest>&from=<other_name>`  <sup>[end-11](#endpoints)</sup>.
@@ -372,6 +372,10 @@ The Location header will contain the registry URL to access the accepted layer f
 header returns the canonical digest of the uploaded blob which MAY differ from the provided digest. Most clients MAY
 ignore the value but if it is used, the client SHOULD verify the value against the uploaded blob data.
 
+The registry MAY treat the `from` parameter as optional, and it MAY cross-mount the blob if it can be found.
+
+It MAY cross-mount the blob referred to by the `mount` parameter even if the `from` parameter is omitted.
+
 Alternatively, if a registry does not support cross-repository mounting or is unable to mount the requested blob,
 it SHOULD return a `202`. This indicates that the upload session has begun and that the client MAY proceed with the upload.