import: proposed changes

Our importer algorithm is a bit out of date and ineffecient due to cruft. I'm hesitant to change it without the tests in place, but here is my conception. We might reject this bug if we decide not to do it, as well.

1) Rather than do an import-attempt-per-new-publishing-record from Launchpad, obtain a list of <version> "objects" where an object is only in the list if <version> has not been imported before (no such tag) or <version> has been imported before but with different contents, using the cache to determine what set of Launchpad publishes to consider. This means we'll have a sequence of SPI objects, in version order, I think, which we will call new_spis.

Notes: If a given version appears twice, it is because it was re-published with different contents. We currently do not have a clean way to distinguish more than two uploads of the same version with different contents. While that should not happen, I don't think we should rely on ftpmaster or Launchpad behavior in the algorithm (as it leads to special casing). We currently use an orphan tag for the first time, but if it happens again, we won't and I believe we emit an error. I wonder if we can just not use the orphan tag and perhaps we should have levels of versioned tags (e.g. import/<version>/0, import/<version>/1) which we iterate to see if the treeishs match? This can be in a function that looks for a single-level tag preferentially else iterates and returns a found tag or None. The semantics of our tags is different now as we only expect to see one tagged commit for any given version?

2) For each spi in new_spis, import it patches-unapplied. No branches are manipulated in this step.

3) For each spi in order, import it patches-applied. No branches are manipulated in this step.

4) For the current archive status of the source package in the itertools.product of (series/pocket), update the correspondig branch pointer

Notes: this makes the devel case and the normal case identical, I think. We could just abstract out that function to take a series and the corresponding launchpad data?

Effectively, we update the commit graph and then we forcibly update where the branches are in the commit graph. From an efficiency perspective, we can probably limit 4) to the series (or even series+pocket) seen in 1)?