feat: simplify auto check update logic by removing platform policy check

[qiuzhiqian]

Bug: https://pms.uniontech.com/bug-view-359323.html

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: 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

[github-actions]

CLA Assistant Lite bot:
提交邮箱中包含我们的合作伙伴，但您似乎并非合作伙伴的成员或对接人，请联系相关对接人将您添加至组织之中，或由其重新发起 Pull Request。
The commit email domain belongs to one of our partners, but it seems you are not yet a member of the current organization, please contact the contact person to add you to the organization or let them submit the Pull Request.

xml seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You can retrigger this bot by commenting recheck in this Pull Request}

[deepin-ci-robot]

deepin pr auto review

这份代码 diff 主要做了两处修改：

1. 在 manager.go 中移除了与 PlatformUpdate 相关的分支逻辑（handleAutoCheckWithPlatform 和 checkPlatformPolicy 方法）。
2. 在 manager_update.go 中调整了 updateSource 方法中 updateAutoCheckSystemUnit 的调用位置和错误处理逻辑。

以下是对这两处修改的详细审查意见：

1. 逻辑与功能变更分析

变更点 1：移除 PlatformUpdate 相关逻辑

• 变更内容：删除了 handleAutoCheckWithPlatform 函数、checkPlatformPolicy 函数，并在 handleAutoCheckEvent 中移除了对 m.config.PlatformUpdate 的判断。
• 审查意见：
  • 逻辑一致性：删除这些代码意味着系统不再支持“基于平台策略的自动检查”。无论 m.config.PlatformUpdate 配置为何值，handleAutoCheckEvent 现在都会直接执行 updateSource。
  • 风险提示：这是一个较大的功能删减。请确认业务上确实不再需要“平台策略控制更新”的功能。如果 m.config.PlatformUpdate 仍然是一个有效的配置项，那么现在它已经失效了，这可能会导致旧配置或特定环境下的行为不符合预期。建议检查 m.config 结构体，看是否需要同步废弃 PlatformUpdate 字段，或者文档是否需要更新。

变更点 2：调整 updateAutoCheckSystemUnit 的调用

• 变更内容：
  • 修改前：updateAutoCheckSystemUnit 被包裹在 defer 匿名函数中，且位于 m.jobManager.UpdateSource 之后。它依赖于 err1 的作用域，且无论 UpdateSource 成功与否（只要 m.jobManager 不为空），都会尝试执行。
  • 修改后：updateAutoCheckSystemUnit 仍然在 defer 中，但移除了嵌套的 if err1 != nil 块。它现在独立于 err1 的检查，直接执行。
• 审查意见：
  • 代码质量（正面）：修改后的代码逻辑更清晰。原来的代码中 err1 变量复用且嵌套逻辑稍显晦涩。现在的结构表明：无论 UpdateSource 是否成功，只要进入 defer 块，都会尝试更新系统单元（Systemd timer 等）。
  • 潜在逻辑变化（需注意）：
    • 原代码中，如果 m.jobManager 为 nil 导致 err1 赋值失败（虽然不太可能，因为前面有判断），或者逻辑流有变，行为会受影响。
    • 新代码中，updateAutoCheckSystemUnit 的执行不再受限于 err1 的状态。这通常是一个改进，因为即使更新源失败，重设定时器（以便稍后重试）通常也是合理的操作。

2. 代码质量与语法

• 语法：代码语法正确，符合 Go 语言规范。
• 代码风格：
  • 在 manager_update.go 中，使用了 if err := ...; err != nil 的惯用写法，比原来的 err1 = ...; if err1 != nil 更简洁且作用域控制更好。
• 冗余清理：删除 manager.go 中不再使用的函数有助于减少代码维护成本，前提是确认功能不再需要。

3. 代码性能

• 性能影响：无显著性能影响。主要是控制流的改变，没有引入新的循环或复杂计算。

4. 代码安全

• 安全性：本次变更主要涉及业务逻辑调整，不涉及明显的输入验证漏洞或内存安全问题。
• 健壮性：
  • 在 manager_update.go 中，updateAutoCheckSystemUnit 的错误仅被 logger.Warning 记录，未中断流程。这是合理的，因为更新定时器失败不应阻塞主流程（如更新源）。
  • 建议确保 updateAutoCheckSystemUnit 内部实现是幂等的，防止重复调用导致状态异常。

总结与建议

1. 确认业务需求：最关键的是确认移除 PlatformUpdate 分支是符合产品预期的。如果这是为了简化代码或废弃旧功能，建议同步清理相关的配置项定义和文档。
2. 单元测试：
   • 针对 handleAutoCheckEvent，需要更新测试用例，移除针对 PlatformUpdate=true 场景的测试，并确保直接调用 updateSource 的路径被覆盖。
   • 针对 updateSource，需要验证在 UpdateSource 报错的情况下，updateAutoCheckSystemUnit 是否依然被正确调用。
3. 代码审查通过：如果上述业务逻辑变更得到确认，代码质量和逻辑改进是值得肯定的。