LocalTopologyManager should not install a reset topology before conflict resolution

When the coordinator changes, either because the old one left or because there was a merge, the new coordinator first resets any ongoing rebalance, and then starts a rebalance with the new members. But some nodes could see the post-merge rebalance before the post-merge reset, and they need to reset any old data or inbound transfers first.

LocalTopologyManagerImpl is responsible for faking that reset topology update, in order to keep StateConsumerImpl simpler. The problem is that LocalTopologyManagerImpl also creates a reset topology update if the new coordinator started conflict resolution, and that topology update clears all the segments not owned by the local node in the preferred topology.