Extracts the cron schedule registration out of `runServeCmd` and into a
new `cmd/fleet/cron_registration.go`. Same pattern as the prior
extractions on this issue (#44929, #45343, #45583, #46166, #46421,
#46517, #46742, #46830, #46893, #47151). This is the largest slice so
far — `runServeCmd` drops from ~1300 to ~1000 lines, and `serve.go` from
1776 to 1472.
The 33 `StartCronSchedule` registrations move into one
`startCronSchedules` entry point backed by a `cronSchedulesDeps` struct
(the dependencies the closures previously captured from `runServeCmd`).
Registration is grouped by domain:
- `registerCleanupAndMaintenanceCrons` — chart data collection, the
`cron_stats` cleanup goroutine, software migrations, frequent cleanups,
cleanups-then-aggregation, query results cleanup, upcoming activities,
usage statistics, batch activities.
- `registerVulnerabilityCrons` — the vulnerabilities schedule, or the
remote-trigger proxy when processing is disabled on this instance.
- `registerWorkerCrons` — automations and worker integrations.
- `registerMDMCrons` — Apple MDM worker, DEP profile assigner, service
discovery, the Apple/Windows/Android profile managers, the Android
device reconciler, the Android policy migrations, and the APNs pusher.
- `registerPremiumCrons` — iPhone/iPad refetcher and reviver, maintained
apps, VPP app version refresh (and the one-shot VPP country backfill),
recovery lock passwords, managed local account rotation, activities
streaming, and the calendar schedule.
- `registerMiscCrons` — host vitals label membership and the batch
activity completion checker.
Behavior is preserved — the schedules register in the same order with
the same arguments, the same conditionals gate them (premium, audit log,
env vars, software store presence), and the `config` is threaded as a
pointer so the `&config` and `config.Calendar` mutations inside the
calendar closure keep their original semantics. `cmd/fleet/cron.go` (the
schedule definitions) is intentionally untouched; only the wiring moved.
One unit test added: `TestVulnerabilityProcessingDisabled` covers the
vuln enable/disable predicate extracted into
`vulnerabilityProcessingDisabled`, including the legacy
`current_instance_checks` `"0"` value. The rest of the file is
dependency-wiring relocation with no further decision logic to unit-test
— those paths construct real schedules, so they stay covered by the
existing suite and integration tests. The full `cmd/fleet` suite passes
against MySQL + Redis, and a local server boot confirms the same 30 cron
schedules start as before (verified against the "started cron schedules"
log line).
**Related issue:** Refs #33370
# Checklist for submitter
- [x] Added/updated automated tests
- [x] QA'd all new/changed functionality manually (verified via local
server boot — same 30 cron schedules start)
- Changes file: not applicable — internal refactor with no user-visible
behavior change
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Centralized background cron schedule startup and standardized job
initialization sequencing for maintenance, vulnerability handling,
integrations, MDM workflows, and premium tasks.
* **New Features / Behavior**
* Added config- and license-controlled enablement for vulnerability
processing (local vs remote triggering), MDM automation (including APNs
delivery and device reconciliation), and premium-only refresh/recovery
behaviors.
* Made chart data collection and optional activity streaming
configurable, with safe fallbacks for scheduling periodicity.
* **Tests**
* Added coverage for vulnerability-schedule enable/disable decision
logic.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Rajendra kadam
dcf5203ff4