Use the creation timestamp returned by the Container Registry API in cleanup policies
## :fire: Problem Currently, [cleanup policies](https://docs.gitlab.com/ee/user/packages/container_registry/reduce_container_registry_storage.html#cleanup-policy) are slow for a main technical issue: getting the creation timestamp of a single tag is a Container Registry API request. As we can imagine, the more tags we need to process, the more pings to the Container Registry we're going to trigger. We improved the situation around this using caching in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69459. ## :fire_engine: Solution With https://gitlab.com/gitlab-org/container-registry/-/issues/708, we're planning in improving the Container Registry APIs, in particular, the amount of information returned by the "tags list" endpoint. When that improvement is available, cleanup policies background jobs need to be updated to use that new API. The use of a gitlab~7884237 is strongly advised here. ## :gear: Caveats https://gitlab.com/gitlab-org/container-registry/-/issues/708+ is available on the GitLab Container Registry where the metadata database is available. At the time of this writing, this setup is only used on ~"gitlab.com". As such, the changes of this epic are only impactful for ~"gitlab.com". When the metadata database feature for the Container Registry is released for ~"self-managed", all GitLab instances (using the GitLab Container Registry) will use the performance improvements of this epic. ## :crystal_ball: Other considerations * If the Container Registry API can return the creation timestamps along with the list of tags, then caching is not really needed anymore. Consider removing caching. * Revisit the admin [settings](https://docs.gitlab.com/ee/user/packages/container_registry/reduce_container_registry_storage.html#set-cleanup-limits-to-conserve-resources) for the cleanup policies. By reducing the count of Container Registry API requests, we improve the efficiency of background jobs for executing those policies. We can thus tweak the settings: * Tags list truncation might not be needed anymore * The amount of concurrent jobs could be reduced. Consider updating the default value for this setting.
epic