Implement asynchronous/background job execution for deliver_contents

[payamnj]

Summary

Currently, the deliver_contents job (both the management command and the DeliverContentsJob class) runs synchronously, processing each delivery in sequence. This approach:

• Causes the entire command or API call to block until all deliveries are finished
• Delays HTTP responses for the /api/jobs/deliver_contents/ endpoint, potentially causing timeouts
• Limits scalability when there are many deliveries

Motivation

1. Async/background execution: By running the main loop or its significant parts asynchronously (or as a true background task), we can:
   • Avoid blocking the HTTP request cycle when triggered by the API endpoint
   • Allow immediate 202 responses with actual background processing
2. Parallel processing: Processing deliveries in parallel (async tasks, thread pool, or integration with Celery/RQ/asyncio tasks) can significantly speed up bulk deliveries.

Acceptance Criteria

• The management command deliver_contents and DeliverContentsJob can execute delivery processing as a background process, not blocking the caller
• The DeliverContentsJobView API (/api/jobs/deliver_contents/) triggers the job and returns immediately (with true 202 semantics)
• Document job execution mode and any new configuration in the README and/or technical docs

Potential Approaches

• Integrate with a background task processing library (Celery, Django Q, RQ, etc.) OR use Python threading/asyncio if sufficient
• Support status tracking or logging for externally triggered jobs

---

References:

• Current job view implementation
• Current job run loop

Rationale: Async job execution is a common Django/CMS/email platform enhancement, allowing better scale, reliability, and modern API ergonomics.

---

Related to project: django-email-learning.