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 $1182 to business
templates not yet covered by coding style test

See merge request nexedi/erp5!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

See commit c45c2295
("erp5_web_shadir: more useful checks").

This fixes how the builder processes the result of IMovementGroup.test.
Testing deliveries to find one that can be updated should have no impact
on properties if the builder ends up creating a delivery.

When i upgrade/install erp5_notebook in an instance which use neo storage instead
of zeo, Neo stopped immediately, as consequence, erp5_notebook can't be installed/upgraded.

The reason is in erp5_notebook, there has a one big file scipy.data.bin 157MB [1] which can't be
installed as it is  in neo. The solution suggested by @jm is to wrapper it by Pdata when install
a BT5.

See merge request !953

[1] https://lab.nexedi.com/nexedi/erp5-bin/blob/7d3505fd/bt5/erp5_notebook/SkinTemplateItem/portal_skins/erp5_notebook/scipy.data.bin

In 44e0b22f (Move to new API, detailed properties take precedence,
2011-09-09) we introduce a new data model for coordinates, in the case
of emails, we have "url_string" fro the "detailed" form and
"coordinate_text", for the "store what user entered" form.

In some places of erp5_credential, we use setDefaultEmailText, which
calls Coordinate.setText which uses the deprecated Coordinate.fromText,
which sets the same value for "url_string" and "coordinate_text", which
seems a questionable behavior, because the data is saved twice and
some code might be using the wrong property.

This changes every usage to the new coordinate_text property

This backports parts of zope 4 commits [bb7837c66 (Explicitly make all
classes new-style., 2017-09-15)](https://github.com/zopefoundation/Zope/commit/bb7837c66) and [173658008 (Fix unpickling of instances
those base class changed to a new-style class. (#208), 2017-10-24)](https://github.com/zopefoundation/Zope/commit/173658008) for zope2.

This is done for two reasons:
 - so that business template XML are same when exported from zope4
   and from zope2
 - so that a business template created from zope4 can still be
   installed on zope2.

See merge request nexedi/erp5!1596

This is used to trigger recompilation of bytecode, but we don't
export the byte code so we don't need to export it.
This also prevent diffs when the Script_magic changed, like it's the
case with Products.PythonScripts 4.2 , with commit 590125a (Force
recompilation of scripts., 2017-10-23).