use a valid image in testERP5ImageProcessor, this test evolved and
became a test for ERP5 behavior with broken images.

This indirectly solves a failure with testERP5ImageProcessor
and PYTHONHASHSEED: 805

When we --load, the sql dump is supposed to be up to date, we don't
need to update translation table every time. This is mainly to solve an
issue that it might not be possible to run ERP5Site_updateTranslationTable
at this point, with testUpgradeInstanceWithOldDataFs this script uses
a print statement, which causes a SyntaxError.

Unit test written by Rafael Monnerat.

See commit 3d7d6d5e.

See merge request !1894

* set _game_duration as an unix epoch
* provide timestamp to onStart function
* add max_command_frequency, if direction commands (setTargetCoordinates
  and loiter) are send more often than max frenquency the drone crashes

See merge request nexedi/erp5!1895

91cc6c4e (ERP5Type/Utils: configure warnings in zopewsgi, 2024-02-16)
was bad, on python2 zope did not start.

    Action on portal_types just invoke updateRoleMapping on all portal types that have
    at least one Role.

    This is useful whever you change way too many roles and you can to ensure that
    everything is updated.

See merge request nexedi/erp5!1893

This uses `from __future__ import print_function` from "unrestricted" python code.

For restricted python in python scripts, this expects SlapOS to have nexedi/slapos!1536 .
Running ERP5 with this patch on an old SlapOS software release should probably be OK,
especially because after all we don't have so much critical code using print.

To ease migration of custom project code, PythonCodeUtils was modified so that
when running CodingStyle python scripts are checked with print_function future enabled.

See merge request nexedi/erp5!1883

  Since the test() method was fixed the comment became irrelevant

Returning true allows to add movements to existing one, and this group shall
always separate them.

See merge request nexedi/erp5!1891

Rename triggerParachute function into land in DroneManager for
compliance with multicopters APIs.

See merge request nexedi/erp5!1880

I investigated a case where activities calling an external API were not
retried after the initial failure, when it was caused by
TimeoutReachedError:

https://lab.nexedi.com/nexedi/erp5/-/blob/f41b33cd91348a800db3b95b30efd857f583bcde/bt5/erp5_web_service/MixinTemplateItem/portal_components/mixin.erp5.RESTAPIClientConnectorMixin.py#L142

The interesting thing is that these activities are written in a way that
allow them to be retried (automatically, or manually) without causing
un-intended side effects, like creating twice a document in the external
API. So not having SQLBase retrying them automatically is a pity.

The bug is that the use of TimeoutReachedError here was intended only
for the activities that are aborted by CMFActivity itself, and not for
the userland code that can also use TimeoutReachedError.

This commit removes this special processing, as there is no need to
especially not retry the activities that trigger the CMFActivity
timeout. The max_retry decision should be taken by the calling code, and
not by CMFActivity.

This flags python2 style usage of print as a statement

(not yet for scripts under portal_skins)

adjusted (by Jérome) to just remove call to print in a few places where
it made more sense.

See merge request !1889

See merge request !1887

 Move Simulation to priority 3 helps to not block/delay immediateReindex
 on a scenario where everything is expanding. We use priority 3 to match
 what is used in SimulableMixin.updateSimulation and Delivery.localBuild

This fixes compatibility for python3, especially with hash randomization
(PYTHONHASHSEED) turned on.

This also enables coding style test that was not running for this bt,
after fixing everything flagged by coding style test.

See merge request nexedi/erp5!1892

Make sure we see *all* warnings, both in the tests and in the logfile in production.

Fix many warnings by updating imports and calls to deprecated APIs

See merge request nexedi/erp5!1879

for consistency and because it's probably good to let user choose
sending mode.

This matches the form title