Fix index/unindex race-condition
Warning: this merge request is based on commits already part of !893 (closed) . That merge request contains generic cleanups which are required for this approach, but also should be good independently from it.
This merge request contains the implementation-specific part, which require a decision on the way we want to go.
The issue is that if one deletes an object while it is being indexed (=indexation activity already running, and not finished yet), the unindexation activity will be able to immediately execute (the serialization_tag dependency is ignored, because the activity it depends on gets deleted by the object deletion code).
This fix just stops deleting activities when deleting a document: activity dependency becomes functional again, and catalog consistency is restored.
The last patch (testERP5Catalog: Test indexation/unindexation parallelism.) adds a test which fails on its very last assertion when ran before the fix (EPR5Type.CopySupport: Do not delete activities for deleted document.) and succeeds when ran after the fix, proving the current bug exists and that the fix actually fixes it.
testERP5Catalog: Check that deleting "a/b" then "a" unindexes both. is a test which works both before and after the fix, and which I think covers something which was not tested so far.
BusinessTemplate,TrashTool: Do not trigger (un)indexation when preserving/trimming subobjects. is required only if the main fix is applied (otherwise spawned activities get removed anyway) and only fixes the tip of the iceberg: updating/reinstalling a Business Template serialises & deserialises the same object multiple times. The ultimate fix should improve BT performance significantly (just because [de]serialisation is known to be slow), but I believe we do not care about this as another implementation is being worked on (?), and the changes required would likely be quite invasive.