EZP-30823: [7.x] Isolated cache during transactions to avoid race condition

[andrerom]

Question	Answer
JIRA issue	EZP-30823
Bug/Improvement	yes
New feature	no
Target version	7.5+, but depends on #2740 being merged first as this is for conflict resolution during merge
BC breaks	no
Tests pass	yes
Doc needed	no

During attempt to backport the transaction isolation fixes done in #2703 a few cases where we should go a bit further appeared:

• Avoid stale data within transactions:
  • Mark items that has deferred delete/invalidation as a "cache miss" when retrieved from shared pool
  • Merge in in-memory handing in order to make sure in-memory cache is always cleared directly and not deferred to avoid using stal
• Avoid creating potentially stale data in shared cache pool:
  • Handle save during transaction => map to a deferred delete by key
  • Cache should only be updated when outer transaction finishes, inner transactions don't show up for other processes.
  • Rollbacks should not commit changes. And in SQL they break out of any level transaction by default, align with that
• BENEFIT: Take advantage of this to get rid of full cache clearing during rollback

REVIEW NOTES:

• The two Decorators we had has been merged into 1 in order to be able to handle in-memory cache during transaction changes

REVIEW QUESTION:

• Should we keep ezpublish.cache_pool.inner and instead remove the decoration?
• Ideally should have something to test this across processes, maybe something like a test with transaction which calls on another process to check it's value while still within transaction. If so, how and where?

[alongosz]

Some remarks:

[andrerom]

@webhdx What's your POV/Review here?