experimental changes for referrers API, ORAS artifact manifest support

[aviral26]

This PR addresses a subset of tasks mentioned in #4 and adds experimental changes that support:

• PUT ORAS Artifact Manifest
• GET ORAS Artifact Manifest
• listing referrers (pagination not implemented yet)

Further reading on usage is available at README.md and implementation at docs/referrers.md.

[sajayantony]

/cc @michaelb990

[SteveLasker]

@aviral26

Note: this PR will be updated to reference the ORAS artifact manifest spec once oras-project/artifacts-spec#17 is merged.

Can you update the PR text to reflect #17 is merged?

[sajayantony]

Can we support up a configuration that would enable this API?

[sajayantony]

Draft guidance for submitting changes to upstream -

https://hackmd.io/batGDY9cSnetgdrAmbVm6g

Branches

This follows guidelines similar to Kubernetes changes gets pushed to upstream.

Source	Description
oras-project/distribution#main	Cut releases through tags
oras-project/distribution#feature_oras_cherrypick	Send this to upstream distribution/distribution#main

1. Actions and other workflow for release will exist in main .
   • oras-release.yaml is an example that will be in the main.
2. main will have all changes that can be upstreamed to distribution through cherry picking to feature_oras_cherrypick

PR hygiene

1. PRs to upstream should have a chronological set of commits.
2. Each commit to upstream MAY squash changes from main to logical reviewable commits
3. feature_oras_cherrypick should have commits that might be sent to upstream as single or multiple PRs and could be rebased of distribution/distribution#main
4. Workflow commits should be easily excludable from main to enable easy cherry picking into feature_oras_cherrypick

[mnltejaswini]

Another thought is to have a separate folder for references

v<root>
└── v2
  └── repositories
      └── nginx
          ├── _manifests
          │   └── revisions
          │    └── sha256
          │        ├── 111ma2d22ae5ef400769fa51c84717264cd1520ac8d93dc071374c1be49a111m
          │        │   ├── link
          │        ├── 222ibbf80b44ce6be8234e6ff90a1ac34acbeb826903b02cfa0da11c82cb222i
          │        │   └── link
          │        └── 333ic0c33ebc4a74a0a554c86ac2b28ddf3454a5ad9cf90ea8cea9f9e75c333i
          │            └── link
          └── _references			
  	      └── subjects
  		     └── sha256
  	    	         └── 111ma2d22ae5ef400769fa51c84717264cd1520ac8d93dc071374c1be49a111m
  			     ├── digest(application/vnd.example.artifact)
  			     │   └── sha256
  			     │       └── 222ibbf80b44ce6be8234e6ff90a1ac34acbeb826903b02cfa0da11c82cb222i
  			     │           └── link <to manifest in _manifests>
  			     └── digest(application/vnd.another.example.artifact)
  				 └── sha256
  				     └── 333ic0c33ebc4a74a0a554c86ac2b28ddf3454a5ad9cf90ea8cea9f9e75c333i
  					└── link <to manifest in _manifests>

Couple of benefits are, it aligns with the current model where separate folder exists for entity type like manifests, tags, layers etc. In the similar fashion references will represent index for all referrers. In addition , if we extend references to layers, this model can still be used except for that the link refers to _layers blob and doesn't need any change to the _layers folder. Also, there will be no change to the existing folders and hence existing systems need not be checked for any unexpected behaviors with this new structure under _manifests.

[mnltejaswini]

subject is optional, so you may want to check only if it is present