The storage changes to use a read/write lock provide locking
guarantees that we do not need to duplicate in the underlying
storage.
This is predicated on the fact that we do the following:
1. A user before running upgrades the schema of there backend
before giving the logbook/backend to the engine. This means
that the backend upgrade() method does not need to be
thread safe.
2. One engine working on one logbook at a given time.
3. An engine accesses and uses the logbook and its flow/task
details by accessing data via the storage accessor interface.
4. Tasks do not currently get direct access to storage or the
underlying logbook while running (in the future we could
provide access to a storage object, but we would need to have
a contract that ensures a task can not hijack an engines usage
of storage by deadlocking the engine).
Change-Id: I0efd5333928698802d25e1ff124e781f9a4907d9
b78028d285