Analyze work needed to support multiple manifests per tag (for pull-by-sha use case)

Currently Quay allows only one manifest per tag.  If a new version of the manifest is pushed to an existing tag we lose the old manifest.  This can be a problem if a deployment is pulling that image by SHA- their image will no longer by available.  Other registries keep these old manifests around so they can continue to be pulled even if the tag has been overwritten.

Note this is the 'inverse' way to implement the requirement stated in PROJQUAY-2443.

Task is to understand what the impact would be to our data model to no longer GC overwritten manifests.    A few points to consider

• How does our data model and push/pull logic change to support this?
• How does our GC code need to change to support this?
• To avoid excessive manifests from filling up storage, can we cap the number of retained manifests by a configurable parameter?
• Can we feature flag this ability to let existing Quay customers continue to operate with  existing semantics?
• Can we expose metrics to understand how many 'abandoned' manifests exist within a namespace/repo so that we can report on this as part of future showback/quota management features?

Deliverables:

• Basic write up on how we can address the points above
• Simple PoC to demonstrate an approach to implement this if possible (even a small subset of the functionality).