Start retention deletion workers right away, instead of waiting for min snapshot ts to advance (#43115)

As written, the deletion worker won't wake up until the min-snapshot cursor is advanced the first time, even if there is lag between the confirmed-deleted cursor and the min-snapshot cursor.
And if we increase the retention delay, the min-snapshot ts will already be far ahead of the desired ts, so we won't advance it for a long time. So the deletion worker won't wake up.

Instead we should always wake up the worker on the first iteration so that we can start working on any lag there may be.

GitOrigin-RevId: bd99ae0ead48e6d438120b1d97bc45d4b6b57673

Author: goffrie

crates/database/src/retention.rs

@@ -1079,6 +1079,7 @@ impl<RT: Runtime> LeaderRetentionManager<RT> {
         let mut error_backoff = Backoff::new(INITIAL_BACKOFF, *MAX_RETENTION_DELAY_SECONDS);
         let mut min_snapshot_ts = RepeatableTimestamp::MIN;
         let mut is_working = false;
+        min_snapshot_rx.mark_changed();
         loop {
             if !is_working {
                 min_snapshot_ts = match min_snapshot_rx.changed().await {
@@ -1204,6 +1205,7 @@ impl<RT: Runtime> LeaderRetentionManager<RT> {
         let mut is_working = false;
         let mut interval = tokio::time::interval(*DOCUMENT_RETENTION_BATCH_INTERVAL_SECONDS);
         interval.set_missed_tick_behavior(MissedTickBehavior::Delay);
+        min_document_snapshot_rx.mark_changed();
 
         loop {
             if !is_working {