Configurable automatic retries (with backoff) for Webhook deliveries

[ManelCoutinhoSensei]

Actions before raising this issue

• I searched the existing issues and did not find anything similar.
• I read/searched the docs

Is your feature request related to a problem? Please describe.

Today, CVAT webhook deliveries appear to be “fire once”: if the receiver is temporarily unavailable (deploy, brief outage, network hiccup, rate limit, etc.) the delivery fails and there is no built-in automatic retry policy. While manual redelivery exists, it requires operational/manual intervention or external scripts. In practice, this makes webhook-based integrations brittle and forces each downstream consumer to implement its own retry/replay mechanism.

Describe the solution you'd like

Add configurable automatic retry support for webhook deliveries when the HTTP request fails (non-2xx response and/or network/timeout errors). Ideally:

• Per-webhook settings (or global defaults) like:
  • max attempts (e.g., 3–10)
  • backoff strategy (fixed / exponential with optional jitter / ...)
  • retry on which status codes (e.g., 408/429/5xx by default; optionally 4xx excluded except 408/429)
  • per-attempt timeout
• Delivery history should record each attempt (attempt number, timestamps, response codes) and clearly indicate final status.

Describe alternatives you've considered

• Implement retries entirely on the receiver side: doesn’t help if the request never arrives due to CVAT-side transient failures.
• Build an external “replayer” that polls /deliveries and calls the redelivery endpoint: works but adds extra infrastructure and complexity, duplicates logic across deployments, and isn’t as robust as native retries.

Additional context

No response