Followup of https://github.com/odoo/odoo/pull/190407

Aims to re-enable readonly cursor by replacing sequence by tables.

# Chosen solution: one table per signal

Simply replace sequence by a table. The only technical change is that the increments became transactional so we need to commit the cursor. Since the cursor is isolated (outside of any other transaction) the behavior should remains almost the same.

**Note:** a Date field is add mainly for monitoring, and more flexible garbage collecting. it is not strictly necessary.
**Note:** the garbage collection proposes to use  `id < max(id) -10`, even if this may looks wrong `id < max(id)` is good enough, the minus 10 will keep a ten-ish history. This doesn't need to be precise, but this should be good enough since we don't expect to have any concurrent update. (signal_changes transaction only inserts row) 
**This is completely arbitrary and could be replace by `id < max(id)` if it causes any issue.**

**This is the solution with the minimal change, good performance, reasonable complexity**

# Alternative solutions considered but rejected

## Alternative solution A, one table, one sequence per signal

https://github.com/odoo/odoo/compare/master...odoo-dev:odoo:master-fix-signaling-ro-onetable-multisequences-xdo
One table, but using one sequence per signal. Manual select nextval and insert. 

The only difference with solution one is that a single index will be used to get all signals.
This complexifies a little table creation. Performances are quite bad with a simple group by, they are equivalent (slighly better) than this solution but with added complexity.

## Alternative solution B: one table, one sequence for all signals

**SPOILER:** doesn't work
See https://github.com/odoo/odoo/compare/master...odoo-dev:odoo:master-fix-signaling-ro-onetable-xdo for implementation

One table for all signals: Instead of creating one table per cache, create a single table with a "key" column for all signals. This simplifies the creation of the table and signal retrieval (one single group by) but we have less information since the sequence is shared among process.
This can make invalidating a cache/registry without risking a second invalidation a little tricky. 

With solution one, we expect to have increment of one. So when invalidating a cache, we can just do 

`self.cache_sequences[cache_name] += 1`

Unfortunately, this is not correct using a single sequence. Lets imagine that the current value of the caches sequences are

In memory:
```
registry: 1
default_cache: 2
other_cache: 3
```

If we invalidate the default_cache, the new in memory value would be 3, but the real new value after the insert would be 4 since 3 was already used by the other_cache. 

In memory:
```
registry: 1
default_cache: 3
other_cache: 3
```
This means that on the next request, the default cache will be invalidated on check_signaling since `3 != 4`

A workaround for that can be to estimate the next value of the sequence by using the max values of all sequences. 

`self.cache_sequences[cache_name] = max(*self.cache_sequences.values(), self.registry_sequence) + 1`

In memory:
```
registry: 1
default_cache: 4
other_cache: 3
```

This is better but still not perfect. If another concurrent requests increments another sequence, lets say `other_cache` before the current request increments the `default_cache`

Real sequences:
In memory:
```
registry: 1
default_cache: 5
other_cache: 4
```
On next request, 4 != to 5 meaning that both `default_cache` and `other_cache` will be invalidated even if the invalidation for `default_cacheµ came from the current_worker.

Taking the id of the inserted record does not work either since we may miss a concurrent update on the same cache.

So, solution B could work but has more drawback than solution 1 (IMHO)

## Solution C (not tested), one table, one sequence, but used as a message queue

Use a single table but change check mechanism.

The main problem with solution 2 is that it is hard to know what signal is coming from where just based on increments. 
It could be possible to select all signals coming from the table and process them if we have any. The easiest solution could be to store the pid of the process that sent the signal (more simple than keeping a list of sent signal, even if this one is possible too) 

Instead of incrementing the counter when sending the signal and having one sequence for each signal, we can select all signal above the last checked one. The new sequence is the max of all signals, then we can process all new signals except the one coming from the current process. 

The major benefit of this solution is that it may allow to have a more precise signal: we could have a message explaining the change. (the module to invalidate, cache key to invalidate, a cache key to remove from cache....)
But on the topic of cache invalidation, this may look like a better idea on the paper that it is in reality. 

**Note** After discussion t looks like this third solution could have some issue regarding order of commit. It is possible that a transaction will consume a sequence, and commit it after another one with a higher sequence

Process a: nextval (10) (registry)
Process b: nextval (11) (default_cache)
process b: commit
process b: check signaling (11)
process c: check signaling (11)
process a: commit

process b and c will never see  update 10 and miss a registry update