Keep track of repositories to remove after restore

Context

When a user executes a restore via Rake (i.e. bundle exec rake gitlab:backup:restore) the order of operations is to restore the Rails DB before the repositories. The restored Rails DB provides the source of truth for which repositories need to be restored.

When Rake invokes the gitaly-backup restore CLI command, the RemoveAll RPC is invoked on each Gitaly storage being restored. This step ensures the set of repos in Gitaly is consistent with the set of projects in the Rails DB after the restore. In other words, we ensure that repos created after the backup was taken are destroyed. This is important because these extra repos will cause conflicts if a user tries to create a new project in Rails, as Rails would generate an ID that maps to the existing repo.

Proposal

Instead of calling RemoveAll, a better approach would be calling RemoveRepository on each repo that exists in Gitaly but wasn't part of the restore. This has two benefits:

• WAL compatibility. We can deprecate the RemoveAll RPC following this issue.
• More efficient restores. Instead of removing everything and restoring from scratch, we can try resetting repos in-place.