Trying to avoid a potential speculative deadlock:

Actually pushing calls to begin commit on individual touched objects
outside of lock.  This is to allow the following potential sequences:

   evt1 enters first phase commit, tries to commit to obj,
   acquiring obj's lock.

   evt2 tries to acquire write lock on obj.  This acquires
   obj's lock as well as evt1's lock.

if first item was still holding lock on evt1, could get deadlock (evt1
holds evt1.lock and tries to acquire obj.lock; evt2 holds obj.lock and
tries to acquire evt1.lock).

Creating a copy of touched_objs is safe.  By the time we enter first
phase commit, we know that we will never *add* to touched_objs.  We
may remove from touched_objs (if we are asked to backout while we're
in STATE_PUSHING_TO_HARDWARE).  But speculative objects will ignore a
first_phase_commit request for a non-reader/non-writer, and so the
extra call is safe.
Added a comment about why not failing/succeeding a cancelable.
When a derivative speculative object backs out from an event, it
should fail the corresponding speculative future that may have been
waiting for it to complete.  This requirement arises from asynchrony
in committing and backing out events: an event may wait on a
speculative future of an object and then request that object to
backout.  In this case, should unblock the speculative future.