Migrate Slots & Keys Optimizations

[vazois]

This PR adds following optimizations and fixes to migrate operations

• For both KEYS and SLOTS option, we now use a sketch to avoid keeping track of the actual keys in a dictionary which is expensive.
• For KEYS option, when using GETKEYSINSLOT instead of scanning from beginning of the lost implicitly keep track of cursor to scan the remaining part of the log.
• For slots option, allow parallelize the store scan to speedup migration of data.
• For both SLOTS and KEYS option, ensure that live keys are migrated (see notes).

NOTES:
Keys to be migrated are not known in advance. We have to scan the store log and capture the keys that belong to a specific slot. The problem with regular scanning is that we might miss keys that have been read-copy-updated to tail if we scan a fixed region.
The solution is to ScanCursor(BA, TA) and return all live keys that may exist beyond the TA address.
If we can do that and because we guarantee no new keys could be added beyond TA for the associated slot (because the slot is in MIGRATING state) then we guarantee that no keys are missed during migration.
The algorithm is as follows:

• Set slot to MIGRATING (guarantees no new keys will be added for that slot but existing keys can be updated)
• Capture (BA,TA)
• Build BloomFilter (BF) => BF = ScanCursor(BA, TA)
• Change state for key set BF[MIGRATING]
• Send Data by doing another scan. Ensure the scan sends the keys with no versions outside (BA,TA) boundary. Keep an overflow list for keys that have been updated beyond the TA address
• Send the keys from the overflow buffer (keys that have been updated.
• Change state for key set BF[MIGRATED]
• Repeat until (BA,TA) range has been scanned in full.