Bulk sending is queued: the batch wizard stamps sending_data on the moves and
lets the send cron do the work.

Before this commit:
Reset to Draft stayed available while the moves were being sent, so the user
could reset an invoice mid-submission. The invoice then ended up draft with an
accepted submission and could be sent to ZATCA a second time, which ZATCA
treats as a taxpayer compliance issue.

After this commit:
The records are locked on both sides, the way l10n_jo_edi does. Reading the
state instead would not help, as a transaction only sees the snapshot taken
when it started, in which the move is still posted.
1. When submitting, the moves that cannot be locked are skipped, as another
   transaction is already working on them.
2. When resetting to draft, the reset is refused if the records cannot be
   locked, otherwise it applies once the submission it races with committed.

Reset to Draft stays available for invoices accepted in Sandbox and Simulation,
as deleting or resubmitting test invoices is the point of those modes.
Production remains covered by the l10n_sa_edi_is_production check.

Steps to reproduce:
1. Install l10n_sa_edi and onboard a sales journal in Sandbox mode.
2. Create and post two invoices.
3. Select them, Action > Send & Print.
4. Select them again, Action > Reset to Draft.

task-6267293

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#284107