For example, if property_sheet "prop" was moved from BT 1 to BT 2 and BT 1 doesn't exist anymore.

Before this commit we have this order:
1 - install BT 2 ("prop" exist and isn't touched)
2 - remove BT 1 ("prop" is removed)
=> at the end "prop" doesn't exist anymore

After this commit we have this order:
1 - remove BT 1 ("prop" is removed)
2 - install BT 2 ("prop" is readded)
=> at the end "prop" exists and is OK

The way of truncating the index file was an error in git 2.11.0, but it
was not an error with git 2.17.0.

/reviewed-on nexedi/erp5!863

Follow xhtml_style CSS.

This is nearly a copy/paste of renderJS error rendering.

While rendering a field_list gadget in non-editable mode,
the `text_content` parameter was given only in the first `render` call.

/bug #20190204-39AF19
https://nexedijs.erp5.net/#/bug_module/20190204-39AF19

/reviewed-on nexedi/erp5!860

Before we were using up to 10 testnodes per test suite. Push it to 15 testnodes to have
chance to run big test suite (like whole ERP5 tests) in less than 2 hours.

/reviewed-on nexedi/erp5!859

ZODB Components: Use regex to check whether a class of the same name as the Component reference is defined.

Until now, there was a very basic string check which didn't handle such cases:
  class DocumentReferenceAnything():
    pass
  class DocumentReference():
    pass
=> _message_reference_class_not_defined was incorrectly raised as the first class was considered.

This allows to know the node working on test, thus we can redraft
lines when a runTestSuite command fails

Before we were looking only create date of test results to give priority of work to do for a test nodes.
So we had cases where some test suites with medium priority had 5 testnodes, and test suites with
high priority having only 3 testnodes.

So clearly distribute the work depending on the maximum quantity of testnode we want.

Right now we have this scenario:
- test result line is started
- sometimes, runTestSuite fails (like timeout), failure is reported
  but test result line remains started (we don't know yet which
  line is associated with testnode)
- when a test result line is "started" since more than 4 hours,
  test result line is redrafted
- test can be reexecuted
Speed up by removing the need of waiting alarm, by knowing which
test result line is executed by which test node, and by redrafting
immediately the test result line on test node failure

Put auto-generated _getAcquireLocalRoles at the end of mro, removing it
from Base.
Also, document why it is treated specially here.
Also, add _getAcquireLocalRoles methods on a few leaf classes whose
instances fake being portal types, without actually being proper document
instances. At least, the ones which are detected in unit tests. The
proper fix would likely rather be to make them proper document classes,
but this carries data migration concerns which go beyond the scope of
this regression fix (_getAcquireLocalRoles was not possible to override
anymore).

This allows code of movement group to still works when they use
setter/getters defined by property sheets

Fully rewrite portal_simulation.mergeDeliveryList to use builders to reconstruct new
merged delivery.

Add parameter "merge_delivery" to builder. This parameter is used when
merge should be done in such a way that movement group at delivery
level are ignored

For example, testReceiptRecoginition employs numpy matrix calculation methods
that try to utilize all the CPU in the computer. This behavior is harmlfull
when there are several testReciptRecongnition is running in a testnode which
has 40 CPUs.