Allow users to free some space

In the context of &886 I've spent some time thinking about deletion strategies.

Here are my findings.

What can be deleted now?

Feature	Status	Issues / Merge Requests
Discussion Storage	Not implemented at all	#32086 - Determine if an upload is referenced on an issue/merge request #17660 - Manage Discussion Storage #16229 - Attachment Manager
CI Artifacts	Users can delete artifacts the job page and with API CI Artifacts have an expire policy	#17661 - Manage CI Storage #23121 - Ability to query and delete artifacts directly from UI #31271 - Artifacts page Community contribution WIP - Improve management of artifacts * Superseded by `16630` and `16654` !16630 - Artifacts Page Backend !16654 - Artifacts page
CI Traces	Users can delete traces on the job page Archived traces are considered job artifacts
Packages	Users can only delete pages on specific version Looks like we do not delete files from object storage but only DB entries. Need to investigate #12581 (closed)
Registry	Users can delete images on the registry page (it will not release the storage space)	#26818 - Implement Docker Distribution inline Garbage Collection (removal of blobs) #15398 - Retention/expiration policy for container images

Out of scope

Deleting a file from git will not save space and it requires rewriting history. So the following git operations are out of scope:

• Git
• Git LFS
• Design documents
• Wiki

Thoughts

1. I can't see an easy way to harmonize all this kind of storages, each one may need a proper storage manager designed around the feature
2. I don't think we should implement deletion for storages based on git and git LFS, it's a dangerous operation that will rewrite the repo history. (Design documents could be an exception)
3. CI related storages may have a shared expiry policy also for traces. It will slowly free up some spaces once build logs gets older.