Update language on client side referrer list generation to mention replace

[dmcgowan]

When a client pulls down a referrer list to add a new referrer, the current language instructs the client to "append" to the list, however the client should also have the option to "replace" referrers in the list.

[sudo-bmitch]

Currently the manifest delete workflow describes the process to delete an entry from the referrers response when deleting a manifest that has a subject. If we add a replace workflow, would there be a similar process to automatically delete manifests on the push of a new manifest for registries that implement the referrers response? And if so, how should registries that do not support the delete APIs respond to those requests?

[dmcgowan]

The manifest delete workflow would not work with the fallback in any case. It would be reasonable for a registry to reject the delete of a manifest that is currently being referred to via another manifest, such as a referrers index.

I think we should likely add more language about the management and subject manifest, including how a "replace" may work in both the fallback and non-fallback case. There is certainly a hole there where a registry could support the referrers endpoint without supporting manifest delete API. I was thinking of opening a separate issue to discuss how we should update the dynamic content generation language to provide clearer guidance on management of subject manifest (removing, auto-pruning, ordering). The fallback case is more straightforward though since a client can simply replace or remove stale descriptors without worrying about manifest delete. We could add should language about only replacing or removing descriptors of the same or known artifact type though.