GCP log wrt request preconditions

[jiggoha]

The GCP log implementation uses request preconditions to address race conditions.

Case 1:

Tile write failure: implemented in #70.

Entries have been sequenced successfully, but when Integrate runs, writing a tile (partial or full) somehow results in a tile that is different that the one that has already been written. This should not happen.

Case 2:

Checkpoint write failure: implemented in #61.

If there is a race condition in Integrate, one run will fail because the checkpoint will have changed by the time it wants to write its version of the checkpoint. This may happen in race conditions. Since Integrate is idempotent, you just need to invoke the Cloud Function again.

If you are invoking the functions from Cloud Build (as we are in the Armored Witness project), the log operator will need to manually retry the Integrate step of the Cloud Build config that failed OR the log will not be updated until the next time an entry gets added and Sequence and Integrate are invoked. It is okay for the latter to happen wrt integrity of the log; the only consequence is that the log will not include the failed run's entry until the next Integrate call.