When deleting a sub-shard after a failed split operation, the delete shard API unloads the replica cores and then deletes the shard state. But, say there were 2 replicas, if the following sequence occurs:
- 1st replica got deleted
- for any reason, the other replica published "state=active"
Then the overseer can switch slice states and put parent shard as inactive and the sub-shards as active.
We should defensively update sub-shard state back to "construction" and only then invoke the unload action on replica cores.