Parallel-prefetch data in lock

[sdboyer]

At the start of a solver run, it's reasonable to assume that we may want the data returned from SourceManager.ListVersions() for each of the sources given in the lock. Of course, the objective is to not need this data, but still. The problem is, we currently do each of those fetches entirely on demand, and within the main solver goroutine. A better strategy would be to prefetch, in parallel, at least that version data.

It may be suboptimal to do this unconditionally and right away, as there are plenty of cases where we won't end up needing the data at all, so there's no reason to hit the network. A good strategy would probably be that, the first time we break a lock (which is a strong indication that other locks will be broken, and will work transparently with the solver parameters that control change), we pop off goroutines to prefetch everything listed in the lock file.

Doing this is probably predicated on having an internal-only SourceManager decorator. That way, we can avoid intermixing any case-specific state into the proper sourceManager (excepting, of course, the vendor dir to search...but we eventually want to factor that out into a param anyway).

[sdboyer]

#85 implemented this. In addition to the strategy of only triggering prefetching once the lock is broken, prefetching is also triggered - if the dep is not present in the lock - when selecting an atom. It's one of our few opportunities, in the otherwise highly serial, locally-focused solving algorithm, to take advantage of some parallelism.