Address batch endpoint limitations regarding encrypted indices

[DRK3]

The current implementation of the batch endpoint (part of the "Batch" extension, which isn't currently in the spec) has a couple limitations:

1. Updated documents must have the same encrypted indices (names+values) as the original document. If you have different encrypted index name+value pairs and you use the batch endpoint, the underlying database will not be updated correctly and things will not work as expected.
2. For new documents, encrypted indices will be created, but no uniqueness validation will occur. If you use unique encrypted indices (either in old documents or the new documents you want to create), then you should not use this endpoint.
3. Delete operations are slow because they don't batch with other operations. They force any queued operations to execute early. Delete operations don't batch with other operations (including other deletes).

All of these can be fixed.

[DRK3]

Limitations 1 and 2 are no longer applicable as of #237 thanks to the removal of the mapping documents. Limitation 3 also no longer needs to be there now either, so the code just has to be updated to send everything as one big batch request.