shardctrler.migrate()的非原子性和ChangeConfigTo在Concurrent configuration changes下的问题

[YXZ252426]

在claimNextOwnership
A 可能因为读取到 Next==new 而继续，B 也可能因为 QueryNext 失败后仍成功执行 UpdateConfig(new, "Next") 而继续。导致多个ctrler获取ownership

// clainNextOwnership tries to claim ownership of the "Next" configuration
func (sck *ShardCtrler) claimNextOwnership(old, new *shardcfg.ShardConfig) bool {
	nextStr := new.String()

	for {
		nextValue, nextCfg := sck.QueryNext()
		if nextCfg != nil && nextCfg.Num > old.Num {
			return new.Num == nextCfg.Num && nextValue == nextStr
		}
		err := sck.UpdateConfig(new, "Next")
		if err == rpc.OK {
			return true
		}

在migrate
当前 migrate() 不是原子迁移；FreezeShard 成功后失败退出会留下不可自动恢复的 frozen shard

	for {
		if sck.hasConfigApplied(new.Num) {
			return false
		}
		state, err = srcClerk.FreezeShard(move.Shard, new.Num)
		if err == rpc.OK {
			break
		}
		if err == rpc.ErrWrongGroup || err == rpc.ErrStaleNum {
			return false
		}
	}
	for {
		if sck.hasConfigApplied(new.Num) {
			return false
		}
		err = dstClerk.InstallShard(move.Shard, state, new.Num)
		if err == rpc.OK {
			break
		}
		if err == rpc.ErrWrongGroup || err == rpc.ErrStaleNum {
			return false
		}
	}

[Anekoique]

对于第一个问题不知道我有没有理解对，你指的是A 和 B的配置内容相同导致产生多个ctrler？lab的描述应该是thus multiple controllers may invoke ChangeConfigTo with different configuration with the same Num.,产生相同配置这个问题本身可能不存在或者没有价值.Code本身现在只保证了不同配置的正确更新.

第二个问题应该有两种情况：

1. migrate 因为 hasConfigApplied 返回 true 而退出，这种情况应该不会出现问题。
2. Controller 崩溃/被 partition，没有完成迁移，这时源 shard 确实处于 frozen 状态。但 lab 明确保证：tester 会启动新controller，新 controller 的 InitController() 会读取 "Next" 配置，发现nextCfg.Num > currentCfg.Num，然后重新调用 ChangeConfigTo，重新走一遍 Freeze → Install → Delete。由于这些 RPC 通过 Num 幂等，重做是安全的.

脱离Lab的测试和框架，确实缺少超时自动unfreeze 或 shard 自主恢复的机制