[ENHANCE]

[ctrought]

Is your feature request related to a problem? Please describe.
Perform reload events based on a defined schedule, or queue until flag changed.

Describe the solution you'd like
The idea would be that the reload event would be queued and then triggered within a schedule period defined by the user. Here are a couple rough thoughts of how it could be done

Defining Schedules

1. ReloadSchedule API
   A new reloader API (CRD) that would let the user define a cron based schedule that permits a reload event to occur. There should be some kind of selector, that would select one or multiple targets that the schedule applies to. An empty targets list / selector would select all targets.

Permit reloads of nginx & mariadb workloads from 00:00 - 00:30 every day.

apiVersion: reloader.io/v1
kind: ReloadSchedule
metadata:
  name: reload-deployments-overnight
  namespace: example
spec:
  paused: false
  schedule: "0-30 0 * * *"
  targetRefs:
  - apiVersion: apps/v1
    kind: Deployment
    name: nginx
  - apiVersion: apps/v1
    kind: StatefulSet
    name: mariadb

Empty targets selects all workloads (ie. inherited by anything that reloader would fire on in the namespace)

apiVersion: reloader.io/v1
kind: ReloadSchedule
metadata:
  name: reload-all-overnight
  namespace: example
spec:
  paused: false
  schedule: "0-30 0 * * *"
  targetRefs: {}

2. Annotated Schedule
   Define the cron based reload scheduler directly on the workload.

kind: Deployment
metadata:
  name: foo
  annotations:
    reloader.stakater.com/auto: "true"
    reloader.stakater.com/schedule: "0-30 0 * * *"

Queuing Reload

1. (Queued)ReloadEvent API
   A new reloader API (CRD), these would be generated by reloader itself (could be just for queued events.. QueuedReloadEvent, or optionally for all reload events.. ReloadEvent). This would basically queue the reload event and keep track of whether the reload should be executed, and if it has been executed. If there is a schedule defined for the workload (via annotation or ReloadShedule API) matching the ReloadEvent target, the reload event is queued until that schedule is satisfied based on the current time. Once the reload is triggered, the status would be tracked in the CR so that it is not actioned again. If the API were used for all reload events, and no schedule matched it would be triggered immediately which is the current behaviour.

This would also open up the possibility to have some kind of manual flag that needs to be changed if the user would like to trigger the queued reloads themselves, instead of automatically. That flag could be propagated down from the ReloadSchedule CR to the ReloadEvent CR when it is created, and the reload would then be held until someone or something changes the flag.

Metrics could be exported using the ReloadEvent CRs, and the lifetime of those metrics for as long as the CRs are there for. They could be garbage collected by reloader after a configurable amount of time following the successful reloader being triggered

apiVersion: reloader.io/v1
kind: ReloadEvent
metadata:
  name: mariadb-statefulset-05032025-891221
  namespace: example
spec:
  targetRef: 
    apiVersion: apps/v1
    kind: StatefulSet
    name: mariadb
status:
  triggered: false
  triggeredTimestamp: null
  scheduled: true ## <-- once a matching scheduler is satisfied the controller triggers the reload

I know there are a lot of sensitive app teams & apps (unfortunately) from enterprise users that just don't like having their workloads reloaded in the middle of business hours and this feature would appeal to them.

Additional context
Somewhat related to #414