A common pattern thus far has been to communicate between ChangeOps
and subsequent Callables using AtomicReferences in the caller. This
works, but using so many AtomicReferences smells kind of wrong,
particularly since the caller-provided portions of BatchUpdate are
single-threaded.
Instead, create a single class Op, which may have steps for each of
the several phases, including a new repo-updating phase. Each of these
steps is passed in a Context object, which includes a phase-specific
view of the BatchUpdate. This encapsulation prevents operations from
doing unsupported things like adding new operations in the middle of
the execute process.
Ops can now communicate between different phases or with the caller
using instance variables.
Change-Id: Id97dbb772d2e3051d6a74bb8e819d691843a45e1
555ae63f86