`lookups` should throw an error if the number of input keys is too large

[jorisdral]

When calling Database.LSMTree.lookups with large-sized batches of keys, @jasagredo was seeing unexpected NotFound lookup results. The offending code is a typo in a bit-mask that we use while querying bloom filters. This typo effectively limited the number of bloom queries we could perform on a single run to 4096 (hexadecimal: 0xfff), while the limit should have been 65536 (hexadecimal: 0xffff). So under high lookups workloads, this limit would be hit and hence the erroneous lookup results.

Also: this limit should probably not be implicit. Instead, lookups should return an error if the number of input keys ever exceeds the limit of what we can handle in lsm-tree.

Originally posted by @jorisdral in #841 (comment)

[jorisdral]

I'm going to assign priority: medium for now because in practice it is probably relatively hard to hit the limit of 0xffff bloom queries in a single run

[jorisdral]

Or, alternatively, maybe lsm-tree should internally sub-divide the lookup keys into batches before bloom queries so that we can guarantee that we never hit this bloom query limit