Exploring the possible failure modes for in place migration

Continues conversation from: #884 (comment 1256133413)

Given as the import phase is where we are exposed to the highest risk of a corrupted migration, we could consider supporting something akin to a revert or fix flag to return the migration back or re-attempt particular failed attempts.

I agree that we need a good recovery story here, but I think that the potential danger of having a command that drops all the tags from a given database has a tremendous capacity to do harm if it's pointed at the wrong place. Some friction with resetting the import step might be a good thing, if it helps avoids unexpected data loss. We should have a dedicated issue exploring the possible failure modes once we have an initial implementation laid down.

Abstract

Now that we have the two new import methods complete with Import Tool: Add One-Shot Three Step Import (#914 - closed) and Import Tool: Allow Running Import Steps Individ... (#915 - closed), we can start to approach this issue. First, we should remove as many features from the importer as we can. Then, we can begin an in-depth look at the import.

Steps

• remove blob transfer importer option
• remove dangling manifests importer option
• remove single repository import option
• deeply explore failure modes