Global Issue
-----

Each time a save point is created inside a transaction, it creates a
substransaction with its own subxid. As said in the documentation
"The more subtransactions each transaction keeps open (not rolled back or released),
the greater the transaction management overhead. Up to 64 open subxids are cached in shared memory for each backend;
after that point, the storage I/O overhead increases significantly due to additional lookups of subxid entries in pg_subtrans."

https://www.postgresql.org/docs/current/subxacts.html

When the 64 is reach, it causes a huge I/O overhead (waiting for subtrans LRU) on every
transaction and lead to a complete freeze until the transaction that
create that many savepoints is killed.

Problem 1
---------

This amount of save point is reach during an import that eventually
failed. It retries with one savepoint per record. After 10 errors, the
import stops but if those error happen after few hundred correct line.
Hundreds of save point are created with their respective sub transaction
id.

Solution: We only create one savepoint when the import retries for
every record and rollback each time the import face an error.

As consequence, if record depends on previous one imported before the
rollback, some phantom error will appear and if some record sould be in
error due to previous record (unique constraint for ie.) some error can
be missed. Anyway the first error will remain correct.

In addition, in this PR we want to monitor the number of savepoint per
transaction and fire a warning with the stack info when the limit of 60 savepoint per
transaction is reached.

In order to monitor properly all the savepoint, we need to convert the
last cr.execute("SAVEPOINT") to the context manager

Problem 2
---------

Increase rank is call during _post once per partner.
Since https://github.com/odoo/odoo/commit/f12ce318020169b1355538066a8f81f78ecbf007
_do_action_change_account trigger the increase the rank of many partner
in one transaction.

By grouping the call of increase rank by count it reduce drastically the
amount of call to increase_rank and thus the number of savepoint