[FIX] ir.attachment: make filestore GC yield to other transactions

If a long-running transaction holds a write-lock on any row in
ir.attachment, the GC job can wait an indefinite amount of time to
acquire its table-wise SHARE LOCK.

While sitting in the queue for this lock, it will conflict with any
future transaction that tries to acquire a write-lock on any row [1].
So the GC transaction, which would normally execute very fast and
immediately release its lock, will start to block other transactions and
cause severe delays in response time. It basically depends on how long
the tx holding the lock takes to complete... which is unknown.

As a workaround, we force an arbitrary (but short) lock_timeout in the
GC tx before attempting the lock. If it fails to acquire it, it will
fail and raise, causing the whole operation to abort. The cron job will
be rescheduled quickly because it failed to complete, giving the GC
another chance to complete.

10 seconds seems a reasonable compromise, as it gives the blocking
transaction(s) some time to complete before bailing out, yet should
not be long enough to bring the system to a halt due to other
transactions blocked by the GC one. I have no hard data to back this
claim, though.

[1] See the LOCK conflict table in the documentation:
      https://www.postgresql.org/docs/10/explicit-locking.html



closes odoo/odoo#41816

Signed-off-by: Christophe Simonis <chs@odoo.com>