I1ff49315 was a mistake: it sacrifices correctness to reduce
contention on rebuilding. In this case we can't avoid the contention,
at least without a lot of extra work to implement multi-change
rebuilding. The actual proximate reason for that change was that
rebuilding changes would fail due to not being able to open the
ReviewDb in the background thread, which is not in request scope.
createAsync was added before we had a cache of parsed ChangeNotes;
with the cache, performance of iterating over notes shouldn't be
*that* bad. In the ReviewDb case, lookup of changes in ReviewDb is not
really a win compared to the batch Access#get(Iterable) method.
All of this adds up to just deleting the createAsync method and using
the same batch #create(ReviewDb, Collection) method used by
ChangeJson. This is correct and requires minimal implementation
complication. There is still the potential for contention if multiple
changes in the result set are out of date, but in that case
serializing the rebuilds is actually probably better than doing them
in parallel.
Change-Id: I28dab2fda8c0743c7ccb92aa06e0f9d6fbbefa60
31f9c198f8