The performance of a module is much less impacted by the number
of objects than before, at least for kind of total we have in
tests (about 1000 objects)

Round the amounts line by line when validating transactions balances and
showing the totals on an accounting transaction.

Even though float field configurations do not allow users to input transactions
where amounts uses more digits that what makes sense for the selected currency,
we had cases where some transactions generated by custom scripts were "too
precise" and passed the validation because unlike in all reports where we
display sum of rounded values, the check was only rounding the sum, which cause
some transactions with 1.00 on one side and 0.333333 0.333333 and 0.333333 on
the other side to be valid.

The scripts used to display sums on an accounting transaction had the same
problem, they were also showing the rounded sum and not the sum of rounded
values.

Always use textwrap.dedent implicitly so that we don't have to do it in
every test and disable the way of making multi lines scripts by passing
multiple arguments. Now there's only one way to do and every tests use the
same way

getRepositoryList contain all business template repositories, ie:

      ['/srv/slapgrid/slappart4/srv/slapos/soft/c63ba7265399450b28f9ea6d5667a5e7/parts/erp5-doc/bt5',
       '/srv/slapgrid/slappart4/srv/slapos/soft/c63ba7265399450b28f9ea6d5667a5e7/parts/erp5/bt5',
       '/srv/slapgrid/slappart4/srv/slapos/soft/c63ba7265399450b28f9ea6d5667a5e7/parts/erp5/product/ERP5/bootstrap',
       '/srv/slapgrid/slappart4/srv/slapos/soft/c63ba7265399450b28f9ea6d5667a5e7/parts/erp5-bin/bt5']

it seems in random order.

Test was written to use the one from parts/erp5/bt5, but since it just
takes "anything which does not contain bootstrap" it was sometimes getting
erp5-bin or erp5-doc and could not find erp5_configurator_standard business
template.

Change the selection of the repository to take into account that we may also
have erp5-doc and erp5-bin and so that it fails if more than one.

all member of random module are available (because in ZopeGuards, there's a
random.__allow_access_to_unprotected_subobjects__ = 1), SystemRandom class
also is, but Random class was not, even though there should be nothing unsafe
in this.

This is needed if we want to use a random number generator with a fixed seed
to get reproductible results. We could use random.seed module level function
but since this is also used by several things in ERP5 this does not produce
reproductible sequences.

See merge request nexedi/erp5!1265

ZODB Components: TestZodbDocumentComponentReload (e5587493): No need to run other common Component tests.

Before we had the sub-documents exported as properties of container document
for some reason. Now they are exported as separate documents, as expected.

See merge request nexedi/erp5!1261

See merge request nexedi/erp5!1264

runTestSuite accept a --test_node_title argument, which is used in
createTestResult API call, so that task distributor can keep track of which
node executed which task, but since it was not passed, we did not know which
test node executed which test result line.

See merge request nexedi/erp5!1205

Remove some unused code and enable coding style

See merge request nexedi/erp5!1263

Change the conditions from getAggregate to hasAggregate and add a portal_type filter
of getPortalDocumentTypeList, since in reality these check for Attachments that are Document Types
stored in ERP5, so types like 'Internet Message Post' should not be considered.

Plus, xml changes, since there was no commit in these fields in the last 9 years

ZODB Components: Migration dialog: list_selection_name must be explicitly named for mapply() to pass it from REQUEST.

Payments made on the date of previous bank statement but not at 00:00 were
not taken into account in this constraint, which leaded to false positive preventing
to open the next bank reconciliation when previous one had a payment with an
accounting date on the day of the bank statement but not at 00:00

Instead of only checking that an error is reported, check the expected
error message, so that we are sure that this test really covers what
it's supposed to cover.

Now that testnode client is supposed to pass test node title,
make sure that on the server side we can display this information.

runTestSuite accept a --test_node_title argument, which is used in
createTestResult API call, so that task distributor can keep track of which
node executed which task, but since it was not passed, we did not know which
test node executed which test result line.

This was never finished and would probably not be implemented this way,
so let's remove.