Relax referrers requirements

[jonjohnsonjr]

Fixes #357

[jonjohnsonjr]

This needs a way to determine if annotations are not being included in the results

Added a dumb annotation, feel free to bikeshed on naming, whether this should be an annotation or a header, or if hoisted annotations should be the default or omitted annotations should be the default.

This is going to dramatically increase requests for edge cases, from almost all results handled in 2 manifest and 1 refers request, to an unbounded number of manifest requests.

In situations where it would be cheap for the registry to hoist annotations, it will be a similar cost for the registry to just embed the whole artifact in data. This will also save the client a roundtrip.

In situations where it would be expensive for the registry to hoist annotations, this gives the registry an out.

[sudo-bmitch]

Another consideration for the edge case, when one image has a large number of referrers, is the registry may generate and cache the response content. But when multiple clients are used (one verifying a signature, another checking SBOMs, another querying for VEX data, etc), each client may be distinct and, without annotations, need to pull every manifest again to perform client side filtering, multiplying the issue.

[jonjohnsonjr]

I think it's reasonable to expect clients to do some work here. Clients still have artifactType to filter out unrelated things.

[jonjohnsonjr]

I might be satisfied with the existing wording:

A registry SHOULD enforce some limit on the maximum manifest size that it can accept. A registry that enforces this limit SHOULD respond to a request to push a manifest over this limit with a response code 413 Payload Too Large. Client and registry implementations SHOULD expect to be able to support manifest pushes of at least 4 megabytes.

If clients are OK with me returning a 413 for artifacts that embed enough annotations to break our ability to store them, I don't know if we need to add any additional language...