## Description
During the installation of the module `event_barcode`, we have an override of `_init_column` for the `barcode`. We were using the psycopg's `executemany` which is just a syntactical sugar for a loop over an `execute`. So we trigger 1 query (which incurs a network cost when deployed and the database is not on the same machine) per row, currently we have 27 queries (for demo data).

## Solution
We can use SQL syntax:
```sql
UPDATE ... SET ... FROM (VALUES ...) WHERE ...
```
which does 1 update for all rows in one go.

## Implementation details
We could implement this query directly with a simple execute, but it requires a lot of manual construction with the help of `sql. Composed`, because of necessity to insert manually `sql.Literal` used for the tuples of the `VALUES`.
Psycopg2 exposes a function called `execute_values` which is just for this case and makes to code way more legible.
We also generate barcodes only for registrations linked to event that are ongoing or in the future, to improve the speed of the UPDATE itself (we update less rows).

## Reference
task-3430406

Avatax returned positive tax amounts for records with a single line with a negative quantity.

The Avalara documentation specifies that the quantity field should always be positive, even when it's a return or refund [1]. The sign is determined by 'amount'.

Changing the larger, overarching test_*_odoo_invoice tests to include negative quantities was considered but doing so doesn't catch this bug. Those tests ensure Odoo does the right thing with the Avatax responses. That works correctly. Instead the issue lies in the request we send to Avatax. A simple test was added to ensure only positive quantities are sent.

[1] "This quantity value should always be a positive value representing the quantity of product that changed hands, even when handling returns or refunds."
https://developer.avalara.com/api-reference/avatax/rest/v2/methods/Transactions/CreateTransaction/

PS. Before this patch another incorrect behavior occurred on sale.order. The amounts on a line with a negative quantity would flip between positive and negative after each button_update_avatax(). This happened because account_avatax_sale sets price_subtotal on the line from the Avatax response. Since we send price_subtotal as 'amount' to Avatax it would alternate between positive and negative because we also sent the negative quantity. It's not necessary to set price_subtotal (US only has price-excluded taxes and we don't do it on account.move), but because it doesn't cause any immediate issues it wasn't changed.

opw-3431324

Forward-Port-Of: odoo/enterprise#47441
Forward-Port-Of: odoo/enterprise#45095