SMM: Improve RecoveryManager Performance

RecoveryManager.DetectMappingDifferences is very slow when the shard map has a large (e.g. 200,000) number of mappings. We should be able to either improve on this, possibly by decreasing the asymptotic algorithmic complexity or perhaps by using batching.

The RecoveryManager code does the following:

1) Retrieve all LSM mappings from the shard

2) Retrieve all GSM mappings that map to the shard

3) Foreach LSM mapping, look up in the GSM matching mappings to augment the GSM mappings already retrieved

4) Compare the LSM and GSM mappings

We should swap around #3/#4 so that we are only doing deep look ups on mappings found to be potentially mismatched.

Start at RecoveryManager.DetectMappingDifferences and trace the four mapping-retrieval and comparison steps described in the issue. Measure behavior with a shard map containing about 200,000 mappings, then verify that limiting deep lookups to potentially mismatched mappings preserves the LSM/GSM comparison results while improving runtime.

Written by the indexing model from the issue text.