支持 master_quorum 自定义选主 ObjectId 并补齐配置校验

[SisyphusSQ]

背景

当前分支中，master_quorum 的选主 _id 使用代码内写死的固定值。
在主备部署场景下，不同同步任务如果都开启 master_quorum，会共享同一个 election 文档，缺少按任务或实例组隔离的能力。

问题

1. master_quorum 的 election _id 固定写死，无法按实例组配置。
2. 多个独立同步任务开启 master_quorum 时，存在共享同一选主文档的风险。
3. 配置层缺少对 master_quorum 关键字段的显式校验。

目标

1. 为 master_quorum 增加可配置的 election ObjectId。
2. 在开启 master_quorum 时，启动阶段强制校验该配置是否存在。
3. 保持现有 quorum 选主机制不变，仅增强配置能力和可用性。

方案概述

• 新增配置项 master_quorum.objectId，用于指定 election 文档的 _id。
• 在 collector 启动阶段，如果 master_quorum = true 且 master_quorum.objectId 为空，则启动失败并返回明确错误。
• selectLeader() 中不再使用固定 ObjectId，而是改为读取配置中的 master_quorum.objectId。
• 顺带梳理启动阶段的初始化顺序，避免相关能力初始化被选主流程阻塞。
• 更新默认配置文件和相关说明文档，补充新配置项的用途和填写要求。

影响范围

• collector/configure/configure.go
• cmd/collector/sanitize.go
• cmd/collector/collector.go
• quorum/quorum.go
• conf/collector.conf
• README / 配置说明文档

验收标准

• 未开启 master_quorum 时，行为与现状保持一致。
• 开启 master_quorum 且未配置 master_quorum.objectId 时，程序启动失败，并输出明确错误信息。
• 开启 master_quorum 且配置合法 master_quorum.objectId 时，能够正常参与选主。
• 不同同步任务可通过不同 master_quorum.objectId 使用不同 election 文档，互不干扰。
• 配置样例中包含 master_quorum.objectId，避免代码与样例不一致。

风险与注意事项

• master_quorum.objectId 必须是合法的 MongoDB ObjectID 十六进制字符串。
• 如果只修改代码而不更新配置样例，用户开启功能后可能直接启动失败。
• 本次改动不涉及 quorum 选主算法本身，仅涉及选主文档标识和启动流程整理。

非目标

• 不修改现有 quorum 选主算法。
• 不调整 heartbeat、抢主超时等策略参数。
• 不引入新的主备状态管理机制。

[zhongli-james]

开发效率杠杠的！~手动点赞

[zhongli-james]

Issue 描述的问题确实存在且有实际价值。从代码中可以清楚看到：

// cmd/collector/collector.go L181
objectId, _ := primitive.ObjectIDFromHex("5204af979955496907000001")

所有开启 master_quorum 的实例共享同一个硬编码的 _id，如果多组独立同步任务使用同一个 checkpoint 库，确实会互相干扰选主。

需要注意/补充的点

1. ObjectIDFromHex 的错误处理被吞掉了当前代码 objectId, _ := primitive.ObjectIDFromHex(...) 忽略了错误返回。新方案中从配置读取用户输入的 hex 字符串时，必须在校验层做合法性检查（24位十六进制），不能在运行时静默失败。建议在 sanitize.go 的 checkConflict() 中加入：

if conf.Options.MasterQuorum {
    if conf.Options.MasterQuorumObjectId == "" {
        return fmt.Errorf("master_quorum.objectId must be set when master_quorum is enabled")
    }
    if _, err := primitive.ObjectIDFromHex(conf.Options.MasterQuorumObjectId); err != nil {
        return fmt.Errorf("master_quorum.objectId is not a valid ObjectID hex: %v", err)
    }
}

2. 配置命名风格需要统一Issue 中写的是 master_quorum.objectId（驼峰混合），但项目现有配置全部是 snake_case + dot 分隔，如 checkpoint.storage.url、incr_sync.mongo_fetch_method。建议改为 master_quorum.election_id 或 master_quorum.object_id，保持风格一致。

3. selectLeader() 的调用时序问题值得明确Issue 提到"顺带梳理启动阶段的初始化顺序"，但没有说明具体要改什么。从当前代码看 (collector.go L176-191)：
   selectLeader() 是阻塞调用（等待 <-quorum.MasterPromotionNotifier）
   它在 SanitizeOptions() 之后、在开始同步之前执行
   如果要"调整初始化顺序"，需要在 spec 中明确当前顺序的痛点是什么、期望的新顺序是什么，否则 reviewer 很难判断改动是否合理。

4. 向后兼容性方案缺失Issue 中验收标准写了"未开启 master_quorum 时行为保持一致"，但没有讨论：已开启 master_quorum 且正在运行的老版本升级到新版本时怎么办？ 新版本强制要求配置 objectId，老用户升级后会直接启动失败。建议：

• 方案 A：如果未配置 objectId，自动回退到原有的固定值 5204af979955496907000001，仅打 Warning
• 方案 B：配置文件模板中给出默认值，文档中标注为必填
  我更推荐方案 A，对老用户更友好，且不破坏线上运行实例的升级路径。

5. election collection 的 DB 也值得考虑可配当前选主文档固定存在 VarCheckpointStorageDbReplicaDefault（即 mongoshake）库中。如果目标是"按任务隔离"，仅改 _id 是够用的，但如果更进一步，考虑 master_quorum.db 也可配（不同任务隔离到不同 DB），会更灵活。不过这属于可选扩展，不是本次必须做的。

6. 影响范围缺少 quorum/quorum.goIssue 的"影响范围"列表中列了 quorum/quorum.go，但实际上从代码看，quorum.go 的 UseElectionObjectId() 接口本身不需要改，只需要在调用侧 (collector.go) 将硬编码替换为从配置读取即可。这一点的影响范围描述是准确的。

7. 缺少单元测试的验收说明Issue 验收标准都是功能性描述，建议补充测试层面的要求：
   sanitize_test.go 中新增 master_quorum 配置校验的用例
   可选：quorum/ 下增加选主逻辑的单元测试（当前该目录无测试文件）

核心建议：补充配置命名统一规范（snake_case）、老版本升级兼容策略、启动顺序调整的具体描述、以及测试用例要求。改动本身很小，主要是 collector.go 里一行代码从硬编码改为读配置 + sanitize.go 加一个校验块。

[SisyphusSQ]

开发效率杠杠的！~手动点赞

提的这些ISSUE以前都实现过，加上现在有agent，以前开发效率是真的不能比了 哈哈