Hashed storage: extend "Enable hashed storage for all new projects" to "for all new and renamed projects"
Proposal by @toon
When a project is renamed, we
mv its repository and attachments to a new place on disk. So, when we're passively trying to get new projects into hashed storage (the "Enable hashed storage for new projects" application setting), this is an ideal time to convert an existing project to hashed storage as well.
In the Geo case, this also happens to close the rename-may-cause-the-secondary-to-use-the-wrong-repository hole, since an attempt to exploit it will always cause the attacker on the secondary to start examining the hashed storage location, rather than the renamed-to location, for a repository.
This is a relatively small change, and in a GCP Migration context, it would allow us to open GPRD to the public once implemented if we were able to check the newly-labeled "Enable hashed storage for new and renamed projects" checkbox on GitLab.com.
If we're not able to commit to that (and note the presence of some hashed storage bugs - including project export breakage - and the lack of a rollback strategy), this becomes an incremental improvement in the passive rollout case, but isn't hugely compelling.