$INSTANCE_HOME/log only exists in runUnitTest instances, this code had
no effect in slapos instances.

It is a future problem because it depends on the Signals module (part
of ZServer package) and we are removing this dependency in the python 3
port.

For the SynchronizationTool, it was even more problematic because it
can cause the component not to loed, with an error like:

    ImportError: erp5.component.tool.SynchronizationTool: cannot load Component SynchronizationTool (signal only works in main thread)

See merge request !1745

See merge request !1744

Also, manually handle mouseover for highlighting relation field menu lines instead
of using css. Indeed, we have to manually handle possibility that highlight could
be done either by mouse or by keyboard.

For such query with multiple SELECT since mariadb 10.3.38, the error is
no longer a "commands out of sync" ProgrammingError, but a simple SQL
error during the parsing step - and nothing is executed.

Adjust the test to just expect "rror" which would match Error (from
ProgrammingError) and "error" from ("you have an error in your SQL syntax")

- use an explicit table level COLLATE because the default one now
appears in the SHOW CREATE TABLE.
- SHOW CREATE TABLE no longer have COLLATE on columns

Extend test to cover more cases of quantity split move solver

The missing workflow resulted in a bug when moving quantities multiple times, first to one delivery, then to another delivery. Then the same solver process with same decision was used as for the first time even if the first delivery was already delivered or movement was deleted. The reason was that Quantity Split Move Solver did not change to succeeded state after solving, so Solver Process did not change to solved state.

No functional change expected.

Allows triggering the regular not-found error handling path from within
the rendering of a form.

See merge request nexedi/erp5!1737

- improve log result filename
- make all drone parameter mandatory
- drop API defaults
- parameters conditions

this script supported the case of a cluster with only activity family
and no distributing family, in that case one node from activity family
was used for distribution, but this node was also used for activity
processing.
This change to use the node only as distribution and not processing in
that case, because it's not recommended to use a node both for
distribution and processing

mroonga is our recommended full text engine

This does not work on Zope4 and does not seem needed on zope2 either

The code was assuming that we could have only one quantity divergency per
delivery. So improve to support multiple divergencies.

This object was not exported with its actual ID, reindexing cause
warnings in the log, like this:

    2023-02-13 08:13:47,169 WARNING CMFActivity Message dropped (no object found at path ('', 'erp5', 'portal_property_sheets', 'OAuth2AuthorisationClientConnector', 'usable_as_default_property'))
    Traceback (most recent call last):
      File "./parts/erp5/product/CMFActivity/ActivityTool.py", line 282, in getObject
        obj = self._getObject(activity_tool)
      File "./parts/erp5/product/CMFActivity/ActivityTool.py", line 276, in _getObject
        obj = obj[id]
      File "./eggs/Zope2-2.13.30-py2.7.egg/OFS/ObjectManager.py", line 783, in __getitem__
        raise KeyError, key
    KeyError: 'usable_as_default_property'

apply nexedi/erp5$1182 to business
templates not yet covered by coding style test

See merge request !1711

- new API methods
- rename fixed wing drone AIP
- new parameters
- parameters optimization
- parameters validation
- physics implementation
- DroneManager-droneAPIs refactor
- general cleanup and better comments