Using the view `information_schema.columns` is slow compared to a simplified query using PG catalog tables. Here we propose to cherry pick the parts of the view that we actually use.

Below we show the timings of both queries as reported by the system on an upgrade 18->master with a runbot DB (many modules installed). All values are in milliseconds.
```
Original:
    min: 0.931
    max: 16.786
    mean: 1.8790601284296555
    sum: 25750.64
    len: 13704
New:
    min: 0.224
    max: 11.832
    mean: 0.8649024372446001
    sum: 11852.623
    len: 13704
```
Total time spent in queries was halved as seen in the `sum` statistic above.

Technically, the new queries are base on the original information schema view definition as returned by `\d+ information_schema.columns`. With all unused info removed.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#285419
Forward-Port-Of: odoo/odoo#216309

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