Refactor storage batches to use StorageBatchRequest and BatchResult

[mziccard]

This refactors Storage batches to mimic the one in DNS. This makes use of the common BatchResult. This also fixes #364.

Now building a batch and getting the result looks like:

StorageBatch batch = storage.batch();
BlobId firstBlob = BlobId.of("bucket", "blob1"));
BlobId secondBlob = BlobId.of("bucket", "blob2"));
// Users can either register a callback
batch.delete(firstBlob).notify(new BatchResult.Callback<Boolean, StorageException>() {
  @Override
  public void success(Boolean result) {
    // deleted successfully
  }

  @Override
  public void error(StorageException exception) {
    // delete failed
  }
});
batch.update(BlobInfo.builder(secondBlob).contentType("text/plain").build());
StorageBatchResult<Blob> result = batch.get(secondBlob);
batch.submit();
// Or get the result
Blob blob = result.get(); // returns get result or throws StorageException

@Capstan I was wondering: is the limit of 100 deletes per batch call still required?

/cc @jgeewax

[coveralls]

Coverage increased (+0.04%) to 85.78% when pulling 6ceb59f on mziccard:storage-batch into 0a6c6f7 on GoogleCloudPlatform:master.

[Capstan]

@mziccard The 100 deletes per batch is not a strong requirement; it is a guideline. There is a maximum size of 10MB on the batch request payload, in which you could logically fit in more deletion requests. That said, due to some current service implementation details, the service performs better if the batches are split for better distribution. There are also some current scaling implications if you do a quick QPS ramp-up by issuing many simultaneous batches in parallel, so it's better to either slow-start or limit the number of outstanding batches in flight.

[mziccard]

@Capstan Just to make sure I understand: following a previous comment we limited the number of deletes per batch to 100, if the user adds more we split them into more batches. Are you suggesting we should limit the overall number of operations on each batch (not only deletes)? If so, could you suggest a reasonable number of operations at which it would be better to create a new batch?

[Capstan]

@mziccard Yes, I think limiting the overall number of operations on each batch is, at the moment, useful, and for the same reasons mentioned previously. We have not done specific analysis to find out the break-even point for various types of queries. If pressed, I'd say that, in the absence of further information, I would suggest 100. Batch size is about a limitation in load balancing within the batch. The number of in-flight batches is also related to limitations in load balancing across the service… going from zero QPS to millions of (virtual) QPS in a very short span from a narrow geographic location (e.g., one single client) can result in degrade performance.

[coveralls]

Coverage decreased (-0.02%) to 85.72% when pulling e9dbb7c on mziccard:storage-batch into 121783a on GoogleCloudPlatform:master.