B2G invoices are not sent via Peppol but to Chorus Pro (via the
approved platform).
Chorus Pro is the platform with ID 9999 on the annuaire.
Any invoice to partner associated with that platform on the annuaire
is considered B2G (business to government).

From a user point of view nothing much changes, except that they have
to set some additional fields for which we rely on the existing module
`l10n_fr_facturx_chorus_pro`.

From a technical PoV we store the information whether a partner is
behind Chorus Pro in the `peppol_supported_documents` field.
(By putting the special document identifier for Chorus Pro invoices there.)
We retrieve the information whether a partner is behind Chorus Pro / B2G
from the annuaire lookup.


The following new lifecycle statuses have been added. They are
required for the functional tests for the Chorus Pro connection.
- Sent (sent by the platform)
- Suspended
- Completed (to "resume" the "Suspended" state)

See the related IAP PR: https://github.com/odoo/iap-apps/pull/1804

task-6278159

Forward-Port-Of: odoo/odoo#284677

Steps to reproduce
------------------
1. On a bank payment method, enable "Identify Customer".
2. Create a lot of orders paid with this method and invoice them (the customer reporting the issue had 2081 orders).
3. Close the session.

The close takes several minutes, and on a remote database the request is killed by the worker time limit before it completes.

Cause
-----
`_reconcile_account_move_lines` reconciles each group of lines with its own `reconcile()` call, one per payment. Every call creates its partials and triggers the recompute cascade of the ORM, which searches `account.move.line` over the whole set of payments of the session, so the cost of a single call grows with the number of payments.

`_create_invoice_receivable_lines` has the same shape: the values are grouped per payment, so every group holds a single value and the lines are created one `create()` call at a time.

opw-6242303 already batched the creation and the posting of the split bank payments, and the reconciliation of their receivable lines, but only for the orders that are not invoiced. Invoiced orders go through `split_inv_payment_receivable_lines`, which was left untouched.

Fix
---
Gather every reconciliation of the session into a single `_reconcile_plan` call. The entries of the plan are processed independently and in order, so the result is the same as reconciling them one by one, but the recompute cascade runs once instead of once per payment.

Create all the invoice receivable lines in a single `create()` call and dispatch the records back to their payment method or payment afterwards.

Benchmark
---------
Closing a session of 2081 invoiced orders on a copy of the customer database:
- before: 558s
- after: 54s

opw-6458271

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

Forward-Port-Of: odoo/odoo#284783
Forward-Port-Of: odoo/odoo#281495

Problem:
`_compute_electronic_product_code` built `tracking_number_list` by filtering out move lines without a lot_id/lot_name, but kept iterating over the full, unfiltered `move_line_ids`. As soon as a tracked product had an untracked move line mixed in with tracked ones (e.g. a manufacturing byproduct move line with no lot), the two lists fell out of sync: at best tracking numbers got assigned to the wrong move line, at worst `tracking_number_list[i]` went out of range and raised an IndexError.
Solution:
Exclude untracked move lines from `move_line_ids` before building `tracking_number_list`, so both stay the same length and index- aligned. Untracked lines get their own explicit "no tracking number" error instead of breaking the alignment for the rest.

Steps to reproduce:
Open runbot V19 -> go to moves history (Inventory) -> add `electronic_product_code` to list view using studio -> remove filter/select all records -> https://anotepad.com/notes/jwxyskc2

Forward-Port-Of: odoo/enterprise#128521
Forward-Port-Of: odoo/enterprise#123859