The PostgreSQL streaming physical replication notably does not synchonize sequence data[^1].

For sequences that are only used to generate unique IDs (for primary keys), this is not a concern because those IDs *will be* replicated correctly.

However it's a different story for sequences that are used directly. For us it means that on read-only cursors targeting database replicas, the registry and cache generation numbers (`base_registry_signaling` and `base_cache_signaling_*`) will remain fixed and out of sync with the values on the read-write master database.

As a consequence, workers serving alternating read-write and read-only requests will keep reloading the registry or discarding caches, because they will jump between the progressing master sequences, and the fixed sequences on the replica.

For HTTP workers this causes a peformance hit and suboptimal usage of resources, as the registry will be needlessly reloaded after a "sequence jump", or caches discarded.

For Gevent workers it may be much worse, because the registry reloading will *yield* and may be started by hundreds of different greenlets, blocking as many database connections, until the connection pool is exhausted. Repeat and rinse...

Note that the problem could manifest even for a worker that only ever processes read-write requests (like Gevent), because the registry and signaling checks were explicitly done in read-only mode.

As a mitigation, this patch forces the cursor mode to "read-write" during the registry loading and signaling checks, regardless of the actual request mode. This causes some minimal extra load on the master database, but ensures that the signaling checks will always use the correct sequences. The actual request handling, which is the costly part, will still be executed in the dynamically selected cursor mode.

PS: this patch does not change the possibility of having a pure read-only server, with a replica connection used for both the read-write and read-only database connections in the config. One should however be aware that the signaling sequences will never advance, so the replica will not receive the signals.

-----
Note: in master we could overcome this limitation by defining an explicit append-only `base_signal` table, with an `id` PK column driven by a sequence, like all tables. Then, whenever we want to trigger a signal, we would simply insert a row in the table with the corresponding signal:

```sql

CREATE TABLE base_signal (
    id SERIAL PRIMARY KEY,
    signal VARCHAR
);

-- increment signal `registry`
INSERT INTO base_signal (signal) VALUES ('registry')

-- check current signal `registry`:
SELECT max(id) FROM base_signal WHERE signal = 'registry';

```

The `base_signal` table would be properly synchronized and visible on replicas, and could be trivially garbage collected by the autovacuum system. As a bonus, it would also make signaling transactional, in the sense that a transaction would be unable to trigger a signal and then rollback due to a later error. The sequence ID might advance, but the row won't be inserted.

Cfr task-4399456

[^1]: https://www.postgresql.org/docs/16/logical-replication-restrictions.html

Steps to reproduce:
 - Install the planning module.
 - Open Gantt view in day scale.
 - Create a planning slot from 11am to 12pm for an employee whose working hours
   are 8-12 and 13-17
 - The default hours will be shown as 13 to 12

Issue:
 - When an employee works two shifts for example 8-12 and 13-17, and we are
   creating a slot from 11-12, the slot timing will show as 13-12 instead of
   8-12.

Cause:
- here is an example of how the planning slot will be calculated and what is
   miscalculation
 - When click on cell 9-10 the calculated hours
   <table><thead><tr><th>Cell</th><th>shift start time </th><th>shift end time </th></tr></thead><tbody><tr><td>9-10</td><td>|8 - 9| = 1<br>|13 - 9| = 4<br></td><td>|12 - 10| = 2<br>|17 - 10| = 5<br></td></tr><tr><td>minimum</td><td>8</td><td>12</td></tr></tbody></table>
 

   so that slot timining will be 8 - 12

- When click on cell 11-12
  <table><tbody><tr><td>Cell</td><td>shift start time </td><td>shift end time </td></tr><tr><td>11-12</td><td>|8 - 11| = 3<br>|13 - 11| = 2<br></td><td>|12 - 12| = 0<br>|17 - 12| = 5<br></td></tr><tr><td>minimum</td><td>13</td><td>12</td></tr></tbody></table>
   So that the slot timining will be 13-12 which should not be possible

Fix:
- We previously relied on the ```_adjust_to_calendar``` method to calculate the
  resource's working hours. However since the working hour intervals are
  already computed using ```_work_intervals_batch```, we are removing the method
  call to reduce code duplication. Calculate the working hours using
  ```_work_intervals_batch``` and return the appropriate work intervals based on
  the resource's working calendar.

task-3916687

Forward-Port-Of: odoo/enterprise#64961

Some users need to make invoices with 100% discount lines. If they try then will receive this UCFE error that does not let us to validate the invoice in DGI .

> ERROR: CODE 31: Error: El contenido del elemento 'Item' en espacio de nombres 'http://cfe.dgi.gub.uy' está incompleto. Lista esperada de elementos posibles: 'SubDescuento, RecargoPct, RecargoMnt, SubRecargo, RetencPercep, MontoItem' en espacio de nombres 'http://cfe.dgi.gub.uy'. 

In order to make it work we need to adapt the module to accept this kind of lines that actually represent an "Entrega Gratuita" (Indicator 5 in Uruguay)

- We check if the line is a 100% discount, if it is then we marked as Entrega Gratuita when we are creating XML (Indicator 5)
- Now that we can have lines and also invoices with total value 0.0 we need to adapt our XML because if value 0.0 then some tags were not added to the final XML - it was interpreted as False and the result was and invalid XML becasue we were missing a mandatory tag. Now we can tags that have 0.0 value to the final XML.
- Now that we can have lines 0.0 total amount, and also invoices 0.0 total amount, if we are using foreign currency then we need to avoid error computing the currency rate (division by zero). Now we detect this cases and use the date rate. Also, the rate is only been computed when actually we are going to use it.

LATAM 1296 / ADHOC Ticket 83295