GCP log wrt request preconditions

Start by reading PR #70 for the tile write case and PR #61 for the checkpoint write case, then compare their request-precondition handling with the behavior described here. Confirm whether any work remains beyond those implementations, including the need to retry a failed Integrate step in Cloud Build; the issue does not name files or tests.

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

Case 1:

Tile write failure: implemented in https://github.com/transparency-dev/serverless-log/pull/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 https://github.com/transparency-dev/serverless-log/pull/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.