The SFU is a server used to relay streaming between the participants of
a call to provide better scalability and performance than the current
peer-to-peer connections.

The required fields have been added in https://github.com/odoo/odoo/pull/138581

* `/mail/static/lib/discuss_sfu` contains the client code that is used
by the odoo client to interact with the SFU.
From: https://github.com/odoo/sfu/releases/tag/v1.0.0
* The Json Web Token code has been extracted from `web_push` while
adding support for the HS256 algorithm, to be used as the authentication
method between the SFU and Odoo.
* The python code has been updated so that the odoo server requests a
channel from the SFU when going above a participant threshold, and swap
the participants to a SFU connection afterward.
* `rtc_service.js` has been updated to support both peer-to-peer and
SFU modes.
* The `call_context_menu` has been updated to display information
relative to the SFU connection when in SFU mode.

task-2765922

ci-security overview at https://github.com/odoo/odoo/pull/132153#issuecomment-1812568693

This adds e-invoicing via Avalara. It relies on l10n_br_avatax for the
taxes to submit. This doesn't depend on account_edi and instead builds
on top of `account.move.send` which is more flexible.

Eligible invoices can be e-invoiced via the "Send & Print"
wizard. Errors are handled synchronously for single invoices and
asynchronously for multiple. Goods invoices, credit notes and debit
notes can be e-invoiced. It's also possible to correct and cancel
electronically invoiced invoices with `l10n_br_edi.invoice.update`.

Avalara provides two endpoints for e-invoicing [1][2]. The first
provides both tax calculation and e-invoicing, the second provides
only e-invoicing. The first one is most convenient but doesn't fit
well in Odoo. Taxes could change and at that point the invoice is
already posted. We instead opt to implement the second endpoint, and
provide the taxes that were calculated when the invoice posted by
l10n_br_avatax. This response is temporarily saved in
l10n_br_edi_avatax_data and deleted once e-invoicing succeeds.

Some fuctions were extracted in l10n_br_avatax to be reused in
l10n_br_edi, without changing any functionality in l10n_br_avatax. The
only change made to tax calculation is how the hsCode is sent. It
needs to be sent to both the tax calculation endpoint and the
e-invoice endpoint but only the former accepts the hsCode with
periods (.). Removing them works for both endpoints, and is simpler
than having to remove them afterwards for just the e-invoice endpoint.

A separate feature is number cancellation. It notifies the government
a range of numbers in a journal won't be used. It's provided by
`l10n_br_edi.cancel.range`.

This adds l10n_latam_identification_type_id to each demo partner so
there's less to configure. It also sets is_company, which was
forgotten before and makes more sense for these partners. It
additionally sets an address on BR Company Customer which allows easy
testing of in-state transactions (same state as the demo res.company).

We finally add some demo products that have been pre-configured to
test various tax and EDI calculation scenarios.

task-3564171

IAP: https://github.com/odoo/iap-apps/pull/725

[1] https://avataxbr-docs.avalarabrasil.com.br/#/Calculations/payloadTransaction
[2] https://avataxbr-docs.avalarabrasil.com.br/#/Invoice%20Goods/sendInvoiceGoods