Hashed storage sends a Geo repository renamed event

Summary

When renaming a project on a Geo primary with hashed storage enabled, the secondary receives a Geo::RepositoryRenamedEvent.

Steps to reproduce

Rename a repository with hashed storage enabled, at least, once https://gitlab.com/gitlab-org/gitlab-ce/issues/38202 is resolved.

What is the current bug behavior?

Geo secondary receives a repository renamed event, and attempts gitlab_shell.mv_project(same_path, same_path) as a result. Fortunately, this will fail - the destination already exists, and gitlab-shell checks that - but I wonder if we can skip the move entirely.

What is the expected correct behavior?

We shouldn't be attempting mv_project at any time for hashed storage repos or wikis.

Possible fixes

https://gitlab.com/gitlab-org/gitlab-ee/blob/v10.0.0-rc4-ee/ee/app/models/ee/project.rb#L477

/cc @brodock

@nick.thomas Should we not log the repository renamed event on primary or just skip it on secondary?

assigned to @dbalexandre

I think we don't have any cache invalidation issue so better not log the change when hashed storage is enabled for that project. (Because the migration script is not merged yet I think we only have .legacy_storage? available, so we can save if project.legacy_storage?

@dbalexandre @brodock I'm not sure how important the other actions taken on the secondary in response to this event are. Various caches claim to be cleared, for instance.

If those actions need to keep happening, then we should continue to send the event. If it's all useless, we can skip sending the event entirely in the hashed storage case.

mentioned in merge request !3066