[FEATURE] Schedule messages for delivery

[imyousuf]

Is your feature request related to a problem? Please describe.
Instead of instant dispatch we want the ability to schedule a message at a future time. This message should be deleteable before its dispatched. And schedule can be one time or repeated; in case of repeated it can be specified how many times or till when.

Describe the solution you'd like
Introduce a new concept of "ScheduledMessage" which will have a dispatchDate specified; additionally if cron is specified it has to be accompanied with times or until and not both.

Describe alternatives you've considered
Until this functionality is available clients will have to create their own scheduler for this purpose; but that seems too much and hence we will implement it.

[imyousuf]

I have a use case for the scheduled messages feature that would benefit from a specific implementation approach:

Use Case: Event-Driven Scheduler System

We need to implement a periodic scheduler that processes scheduled tasks at specific times. Rather than running a continuous polling loop or cron jobs, we'd like to use webhook-broker to manage the timing of these processes in an event-driven manner.

Proposed Implementation Requirements:

1. Delayed Message Delivery:

   • Allow broadcasting a message with a delivery_after parameter that specifies when the message should become available to consumers:

   POST /channels/{channelId}/broadcasts
   {
     "content": "...",
     "deliveryAfter": "2023-05-15T14:30:00Z"  // ISO8601 timestamp
   }

   • Alternatively, support duration-based delays:

   POST /channels/{channelId}/broadcasts
   {
     "content": "...",
     "deliveryAfter": "5m"  // 5 minutes from now
   }

2. Message Handling Logic:

   • The broker should hold the message until the specified time before making it available to consumers
   • For pull consumers: Messages aren't included in listings until they're due
   • For push consumers: Messages aren't delivered until they're due
   • All other delivery semantics (retries, etc.) remain the same

3. Self-Maintaining Loop Pattern:
   This allows implementation of a very efficient scheduler pattern:

   [Initial Message] → [Process Tasks] → [Schedule Next Message] → [Repeat]
   

   With this pattern, we can build a robust, self-maintaining scheduler with:

   • No continuous polling
   • No separate timer processes
   • Utilization of existing reliability features
   • Simple, event-driven architecture

4. Additional API Features (Nice to Have):

   • Listing pending scheduled messages
   • Updating or canceling a scheduled message before delivery
   • Filtering scheduled messages in the admin UI

Implementation Approach

The implementation could store an additional timestamp field in the job model:

type Job struct {
    // ... existing fields
    ScheduledDeliveryAt *time.Time `json:"scheduledDeliveryAt,omitempty"`
}

The job processor would then:

1. Skip jobs where scheduledDeliveryAt > now()
2. Include these jobs in a "scheduled" status category
3. Eventually process them when their delivery time arrives

This would enable event-driven scheduled processing with minimal polling, leveraging webhook-broker's existing reliability mechanisms.

Would this implementation approach work with the current architecture? I'd be happy to provide more details if needed!