[docs:gsoc26] Add documentation, screenshots and YouTube usage video for persistent mass upgrades

[Eeshu-Yadav]

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

By the time sub-issues 01–09 land, all of these are new and undocumented: the is_persistent checkbox on the confirmation page, retry_count and next_retry_at on the operation detail page, the ?status=pending filter, the two notification flows, the nine new configurable settings spread across sub-issues 02/04/05/06, and the required CELERY_BEAT_SCHEDULE entries. Existing screenshots in the docs also become inconsistent with the new admin UI.

This sub-issue covers the documentation, screenshots, and YouTube video that wrap up the feature.

Describe the solution I would implement

I would like to land the documentation and media assets that make persistent mass upgrades usable for operators and deployers.

1. Add a new "Persistent Mass Upgrades" docs section under docs/user/ (alongside intro.rst, quickstart.rst, upgrade-status.rst, etc.) covering:

   • What the feature is and when to use it (problem statement: offline devices in large fleets).
   • Enabling it from the admin confirmation page (is_persistent checkbox, pre-checked).
   • Enabling it via REST API (POST /build/<pk>/upgrade/ and single-device POST /upgrade-operation/).
   • Finding pending operations (?status=pending filter, retry-count and next-retry-at columns).
   • Cancelling a pending operation (admin button and REST endpoint).
   • Interpreting the two notification flows (reminder vs. failure-needs-attention).
   • Behaviour with vs. without openwisp-monitoring installed (signal-based vs. Beat-only wake-up).

2. Lifecycle diagram showing the new operation state machine: in-progress ⇄ pending → success/failed/cancelled/aborted. Explain the two transitions out of pending (Beat-driven and signal-driven).

3. Document every new configurable setting added across sub-issues 02, 04, 05, 06 (backoff base/multiplier/jitter/cap, scan cadence, two jitter windows, reminder cadence, reminder scan cadence) — defaults and rationale for each.

4. Add a "Required Celery Beat schedule" section explaining the two new periodic tasks (check_pending_upgrades and send_pending_upgrade_reminders) and the exact CELERY_BEAT_SCHEDULE snippet deployers need to add to their settings.

5. Replace existing screenshots affected by the changes:

   • Mass-upgrade confirmation page — now with the is_persistent checkbox.
   • Operation detail page — now with is_persistent, retry_count, next_retry_at as read-only fields.
   • Operations list page — ?status=pending filter selected, pending rows visible.
   • Batch detail page — mixed statuses with the corrected "X complete, Y pending out of Z" progress display.
   • Reminder bell notification — example of the bell with the link to the pending-filtered batch.

6. Update the REST API reference (docs/user/rest-api.rst) with the new fields (is_persistent, retry_count, next_retry_at), default values, the cancel endpoint, and the ?status=pending filter. Include a sample curl invocation for triggering a single-device persistent upgrade — that's the path [feature] Persistent Mass Upgrades #379 specifically calls out for this iteration.

7. Record a short YouTube usage video (~3–5 min): launch a persistent mass upgrade against a fleet with one offline device, show the device land in pending, bring it online (mock or real), show the WebSocket-driven UI update through retry to success. Mention the reminder notification flow and the optional monitoring-signal speedup. Link the video from the new docs section and the README.

8. Update README and CHANGELOG: short "Persistent Mass Upgrades" paragraph in the README features list with a link to the new docs section; CHANGELOG enumerates the migration 0018_* + 0019_*, the new admin/API fields, the new configurable settings, the two new Beat schedule entries, and the optional openwisp-monitoring integration.

[nemesifier]

Updated this issue to align it with the current proposal tracking:

• Renamed field/API/form references from persistent to is_persistent.

To review the body diff, navigate to the top bar of the issue, click on "last edited by nemesifier", then click on "most recent". GitHub does not provide a quick URL for this view.