This follows from investigations in
https://rt.lca2018.org/Ticket/Display.html?id=283&results=eac0bd3c49f782d054f87d6b160ca36b;
in short, it seems that because this very long and complex method
creates several different objects at differnt times, the DB has been
getting out of sync; there are more votes recorded then there are
reviews, becuase the table that stores the vote count is updated
before the table that stores the vote and review information
This change is intended to make this operation (and the other
operations that the revew_detail handler performs) atomic, to prevent
things getting further out of step. It does *not* fix the existing
incosistency.
review_delete has been atomicified as well as it likely needs the same
treatment, but this has not been examined in detail.
5114076afa