Adding interface for partition strategies, removing the need to use cfg,...

[StabbyCutyou]

... adding in new RangePartition strategy, new TimedRingCache for handling locked keyspace ranges

ping @lumost

Still testing. As in, going to write actual tests.

Drawbacks: This requires up-front knowledge of the queue settings, since I removed the dependency on the config object. If those settings change, we'd effectively need to blow the partition strategy, and create it anew.

Also, the Range partitioner has an unlock-window drawback - if you lock ranges:

1,2,3,4,5,6

then realize range 4 was empty and should be unlocked

1,2,3,5,6

Range 4 is not available again until after range 3 expires (in theory, I haven't fully tested forced expiration). This is still better than waiting for 4 to expire naturally, but it isn't great.

We also replace the constraint that used to be set around number of partitions. We would now set a "lockIncrement" value, that says "For each 2i range we try to use, take the last upperBound we handed out, +1, and increase the range by lockIncrement". This gives us a much more granular approach to scan the keyspace for objects.

A further drawback - to make this threadsafe, it's laden with locks. I'm thinking the RangedPartition strategy might actually need to combine parts of the original strategy - a set number of partitions that only serve to set the upper/lower bounds for the TimedRingCaches. More TRCs, more concurrency. One big ass TRC, less concurrency.

Let me know what you think. Obviously needs more work.