This one is tricky, because we can't rely on reading the Change from
the database when constructing the ChangeContext inside the
BatchUpdate, because it doesn't exist yet and comes instead from the
ChangeInserter.
To work around this, add a special type of Op, InsertChangeOp, that
specifies a whole Change instance. These ops require a different
method call, insertChange, and we can enforce that InsertChangeOps are
only used via this method call. InsertChangeOps may be mixed with
non-insert Ops, but the insert happens first, and the Change in the
context is the change returned by InsertChangeOp#getChange() rather
than being read from the database during a transaction.
At call sites, this mostly follows the same pattern as InsertOp,
creating a BatchUpdate where one doesn't already exist, in such a way
that it will be hoisted out later.
Change-Id: Ib8fe154f7a54e4228d338976f317dbd1ee9a6cf7
9e27dec3ff