In the shard registry readme, we don't really explain the mechanism which causes a bump of the topology time to result in a refresh in the next access to the shard registry. We should explain the codepath where the causally consistent methods of the shard registry rely on _getData which advances the timeInStore based on the current topology time prior to fetching information. We should also add information about the non-causally consistent APIs (which should be avoided) that use _getCachedData to avoid this advancement and rather just take the current cached information.