registry.json: Update error codes (e.g. INVALID_DIGEST -> DIGEST_INVALID)

Catch up after [1]:

On Wed, Dec 10, 2014 at 03:48:34PM -0800, Stephen Day wrote:
> Changes:
>
> - Updated error codes based on feedback and implementation
>   discoveries
> - Added full table of all api error codes, their descriptions and
>   encountered statuses

Which added the following to the #9015 summary:

> The error codes encountered via the API are enumerated in the
> following table:

which I've rendered as a list, because the table was too wide to fit
here.

> code: UNKNOWN
> message: unknown error
> description: Generic error returned when the error does not have an API classification.
> HTTP status codes: Any
>
> code: DIGEST_INVALID
> message: provided digest did not match uploaded content
> description: When a blob is uploaded, the registry will check that
>   the content matches the digest provided by the client. The error
>   may include a detail structure with the key "digest", including
>   the invalid digest string. This error may also be returned when a
>   manifest includes an invalid layer digest.
> HTTP status codes: 400, 404
>
> code: SIZE_INVALID
> message: provided length did not match content length
> description: When a layer is uploaded, the provided size will be
>   checked against the uploaded content. If they do not match, this
>   error will be returned.
> HTTP status codes: 400
>
> code: NAME_INVALID
> message: manifest name did not match URI
> description: During a manifest upload, if the name in the manifest
>   does not match the uri name, this error will be returned.
> HTTP status codes: 400, 404
>
> code: TAG_INVALID
> message: manifest tag did not match URI
> description: During a manifest upload, if the tag in the manifest
>   does not match the uri tag, this error will be returned.
> HTTP status codes: 400, 404
>
> code: NAME_UNKNOWN
> message: repository name not known to registry
> description: This is returned if the name used during an operation
>   is unknown to the registry.
> HTTP status codes: 404
>
> code: MANIFEST_UNKNOWN
> message: manifest unknown
> description: This error is returned when the manifest, identified by
>   name and tag is unknown to the repository.
> HTTP status codes: 404
>
> code: MANIFEST_INVALID
> message: manifest invalid
> description: During upload, manifests undergo several checks
>   ensuring validity. If those checks fail, this error may be
>   returned, unless a more specific error is included. The detail
>   will contain information the failed validation.
> HTTP status codes: 400
>
> code: MANIFEST_UNVERIFIED
> message: manifest failed signature verification
> description: During manifest upload, if the manifest fails signature
>   verification, this error will be returned.
> HTTP status codes: 400
>
> code: BLOB_UNKNOWN
> message: blob unknown to registry
> description: This error may be returned when a blob is unknown to
>   the registry in a specified repository. This can be returned with
>   a standard get or if a manifest references an unknown layer during
>   upload.
> HTTP status codes: 400, 404
>
> code: BLOB_UPLOAD_UNKNOWN
> message: blob upload unknown to registry
> description: If a blob upload has been cancelled or was never
>   started, this error code may be returned.
> HTTP status codes: 404
>
> While the client can take action on certain error codes, the
> registry may add new error codes over time. All client
> implementations should treat unknown error codes as UNKNOWN,
> allowing future error codes to be added without breaking API
> compatibility. For the purposes of the specification error codes
> will only be added and never removed.

Almost everything has an obvious analog in the new list, but
UNTRUSTED_SIGNATURE is gone (rolled into MANIFEST_UNVERIFIED until we
have a better feel for the trust implementation [2]).

[1]: https://github.com/docker/docker/issues/9015#issuecomment-66546536
[2]: https://github.com/docker/docker/issues/9015#issuecomment-66548515