fix: Remove features related to the outdated backup and restore system "ab recovery"

[electricface]

"ab recovery" has been superseded by the deepin-immutable system.

Link: https://gerrit.uniontech.com/c/lastore-daemon/+/317933

[deepin-ci-robot]

deepin pr auto review

这份代码 diff 主要是对 lastore-daemon 中的 manager.go 和 manager_update.go 进行了修改。核心改动是移除了对 com.deepin.abrecovery (A/B 分区备份恢复相关功能) 的依赖、调用以及相关的状态变量。

以下是对该代码变更的详细审查意见，分为语法逻辑、代码质量、代码性能和代码安全四个方面：

1. 语法逻辑

• 逻辑一致性：
  • 移除完整性：代码移除了 abObj 字段及其初始化，同时也移除了 preCheckBackUp 函数及其调用点。从逻辑上看，这是一次彻底的功能移除，没有留下"僵尸代码"（即定义了但未使用的变量或调用了不存在的函数）。
  • 状态清理：移除了 preBackUpCheck 字段。审查需要确认：在代码的其他部分（未展示的 diff 中），是否还有读取 m.preBackUpCheck 的逻辑？如果有，这些逻辑现在会读取到结构体的零值（false），可能会导致逻辑行为发生非预期的改变（例如，原本判断为 true 的分支现在无法进入）。建议：全局搜索 preBackUpCheck，确保没有遗漏的引用。
  • 导入清理：移除了 abrecovery 的导入，符合 Go 语言的规范。

2. 代码质量

• 解耦与简化：
  • 移除对 abrecovery 的依赖降低了 Manager 结构体的复杂度，符合"单一职责原则"的改进方向。如果 A/B 备份不再由 lastore 管理，将其剥离是正确的。
• 注释与文档：
  • 代码删除了 preCheckBackUp 函数，该函数原本包含业务逻辑（检查备份状态、启动备份）。删除功能时，建议在相关的 Commit Message 或代码文档中注明移除原因（例如：该功能已下线、或迁移至其他服务），以便后续维护人员了解历史背景。
• 错误处理：
  • 原代码中的 preCheckBackUp 函数在日志中使用了 logger.Info("can not backup,", abErr) 来记录错误。移除该函数后，相关的错误反馈机制也随之消失。建议：确认移除此功能后，系统是否还需要在特定时机（如更新源前）告知用户备份状态？如果需要，应由新的负责方提供接口，否则用户体验可能缺失。

3. 代码性能

• 资源占用：
  • 移除 abrecovery 的 DBus 连接和调用，减少了 DBus 总线上的通信开销。
  • 移除了同步的 StartBackup 调用（原代码中虽然有 0 超时，但仍涉及 IPC 通信），避免了在 updateSource 流程中可能产生的阻塞或延迟，略微提升了更新源检查流程的响应速度。

4. 代码安全

• 权限与依赖：
  • 移除对 com.deepin.abrecovery 的依赖，减少了 lastore-daemon 需要与之交互的系统服务数量。从攻击面来看，减少外部依赖通常是有益的，降低了因依赖服务漏洞导致连带风险的可能性。
• 副作用：
  • 原代码逻辑中，如果备份失败，m.preBackUpCheck 会被设为 false。虽然原代码 diff 中未展示 preBackUpCheck 的具体用途，但通常这种标志位用于控制流程（例如："如果备份未完成，则禁止系统更新"）。
  • 风险提示：移除该检查后，系统更新流程将不再受限于"备份是否完成"。如果 abrecovery 的目的是防止系统变砖，那么移除此检查可能会导致在系统状态不安全（如未备份）时依然执行更新，从而带来系统稳定性风险。建议：务必确认移除此备份检查是经过产品安全评估后的决定，或者是备份机制已经发生了根本性的变化（例如不再依赖此处的同步检查）。

总结与改进建议

这份代码 diff 执行了一次清晰的功能裁剪，语法正确，逻辑连贯。

主要改进建议：

1. 全量引用检查：务必在项目中全局搜索 preBackUpCheck，确保没有遗漏的读取该变量的代码，防止因变量消失导致的逻辑错误（默认变为 false）。
2. 补充文档/说明：在提交记录或相关文档中，明确说明为何移除 A/B 分区备份检查，以及移除后如何保障系统更新的安全性（如果原机制是为了安全的话）。
3. 确认业务闭环：确认 updateSource 流程中不再需要任何形式的备份确认或状态反馈。如果用户侧需要感知备份状态，需确认由哪个模块负责。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: electricface, qiuzhiqian

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment