[saikeerthan-14]

When an idle DB enables ttl or periodic_compaction_seconds through SetOptions, its compaction trigger keeps the period calculated at open. With the default wakeup cap that can delay the first check by 12 hours. Changing the DB wakeup cap through SetDBOptions, or adding or dropping a column family with a shorter time-based interval, has the same problem.

Refresh the existing kTriggerCompaction scheduler task after DB/CF option changes and CF creation or deletion. The scheduler already replaces a task only when its period changes, so unrelated updates leave the timer schedule intact. A multi-CF SetOptions call can apply an earlier CF change before a later one fails; the trigger is refreshed in that case too. This changes wakeup cadence only. It does not change compaction eligibility, public APIs, ABI, or on-disk formats.

The regressions use the scheduler's mock clock and registration callback to verify that the period follows SetOptions, SetDBOptions, CF creation and deletion, including increases when a short interval is removed and a partial multi-CF update. The existing scheduler test is updated to expect rescheduling when stats periods change. A one-line release note is included.

Closes #15251.

Validation

• All 7 periodic_task_scheduler_test tests pass with ASSERT_STATUS_CHECKED=1 on macOS/Apple Clang. The prior version of the patch also passed all 6 scheduler tests in a normal build; the final change adds one checked-status regression and a partial-failure refresh.
• The three trigger-period tests pass 100 repetitions in the checked-status build.
• make check-sources, make check-format, and git diff --check pass.
• A full checked-status make check run on the final production code passed its format gate and reported no failures through 645 of 1,889 shards. I stopped it because the unrelated external-SST test shards were taking a long time; it was not completed. The partial-update regression was added afterward and passed the focused checked-status run.