With python2, iterating on a dictionary or a set always produces the same result,
although this is not a documented behavior. On python3 this is not the case,
because the hashing algorithm is random by default, which can also be set using [`PYTHONHASHSEED`](https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED). On SlapOS, this is done with nexedi/slapos!1535 

This fixes the parts where ERP5 code depends on python2 order, mostly tests, but also places
where we iterate on a dictionary or set. Most of the time, the fix has been to sort so that
the order is deterministic regardless of the hash algorithm randomization, but sometimes we
had to extend a bit the configuration where the order was really important. We did this after
discovering the problematic areas by running tests multiple times with different hash randomization
seeds. It's not impossible that changing from "default python2 order" to "sorted" reveals some
more problems in custom configurations, but this would mean that the configuration must be 
adjusted to use explicit order instead of being lucky with the default python2 order.

The main pattern was the use of `edit` method which edits properties in an order that is a bit
constrained with the `edit_order` mechanism, because some properties depend on other properties,
so it's important to set them in order. This extends a bit the `edit_order` mechanism to specify
more properties that were edited in the right order with `PYTHONHASHSEED=0` by chance.

This also extends delivery builders to edit properties in order defined in the equivalence tester,
most equivalence tester were already properly configured, except the `start_date` and `stop_date`
from delivery level movement groups. That probably only matters for some specific test assertions,
but in practice this was visible in a lot of failing tests.

Some visible changes are that:
 - workflows are now sorted alphabetically on history tab
 - properties are now sorted alphabetically on the diff view of history tab
 - business templates are installed in the order of dependencies and in alphabetic order when they
  are not constrained.

See merge request nexedi/erp5!1882

  Remove forbidden properties when retrieve the properties from the schema.

      - template and options isn't  part of json schema spec, so it isn't possible to use this feature globally.
      - template also could be used to call callbacks, so despite we block unsafe-eval, it still better remove it.
      - both were removed because it can lead to parameter injection, where by saving the form w/o editing anything, it changes the parameters, it adds non-visible values, which can up to some extend be a security risk.

   Update the description to display the "default" value as a hint, if it was provided into the schema.

constructs like `portal_catalog(title=d.keys())` were allowed on
python2, we can allow them on python3 as well.

See discussion in https://www.erp5.com/group_section/forum/Worklists-with-security-uid-columns-wa7gzLN6NG

See merge request nexedi/erp5!1712

With some combinations of worklists using two additional security_uid
columns coming from local role groups, some documents might be excluded
from worklists, without the fix, when running with a random
PYTHONHASHSEED, the test can fail with:

    FAIL: test_worklist_exclusionlist_collision (erp5.component.test.erp5_version.testERP5CatalogSecurityUidOptimization.TestSecurityUidOptimizationWorklist)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "<portal_components/test.erp5.testERP5CatalogSecurityUidOptimization>", line 370, in test_worklist_exclusionlist_collision
        'security_uid_or_alternate_security_uid_draft': 1,
      File "<portal_components/test.erp5.testERP5CatalogSecurityUidOptimization>", line 213, in assertWorklistCount
        expected_count_by_worklist_id,
    AssertionError: {'security_uid_or_alternate_security_uid_draft': 1} != {'collision_worklist': 1, 'security_uid_or_alternate_security_uid_draft': 1}
    - {'security_uid_or_alternate_security_uid_draft': 1}
    + {'collision_worklist': 1, 'security_uid_or_alternate_security_uid_draft': 1}
    ?  +++++++++++++++++++++++++

What happens in sumCatalogResultByWorklist is something like this:

    (Pdb) pp criterion_dict
    {'alternate_security_uid': <ExclusionList [11, 14]>,
     'other_security_uid': frozenset([13L]),
     'portal_type': frozenset(['Person']),
     'validation_state': frozenset(['draft'])}

    (Pdb) pp catalog_result.dictionaries()
    [{'alternate_security_uid': 12,
      'count': Decimal('1'),
      'other_security_uid': 13,
      'portal_type': 'Person',
      'validation_state': 'draft'}]

Depending on the worklists grouped together in grouped_worklist_dict and
the order this dict is iterated, we may reach a situation where
criterion_id_list contains 'alternate_security_uid', because for another
worklist it was not an ExclusionList but a list to be applied, in this
case, this if condition is false:

        for criterion_id in criterion_id_list:
          criterion_value_set = criterion_dict[criterion_id]
          if result_line[criterion_id] not in criterion_value_set:
            is_candidate = False

and the row is not counted in collision_worklist worklist.
Co-authored-by: Jérome Perrin <jerome@nexedi.com>

These are printed like a normal list, so it's a bit hard to figure out
if they are supposed to be excluded when debugging

This refactors security_uid_innodb_catalog test to have the config in a
test business template and include a workflow with some worklists.

This also depends on erp5_worklist_sql, to test worklists when a
combination of erp5_security_uid_innodb_catalog and erp5_worklist_sql
are enabled, which a common situation.

Otherwise we get an error when just adding a worklist

See merge request nexedi/erp5!1900

   This business template introduces a way to adjust mariadb and data.fs after restore from backup. In the occasion that the backups are unsync (which is normal) it helps to push both on sync instead of fully reindex the site.

See merge request nexedi/erp5!1904

   Select sets "1" and "" as values

    The select must display the value regardless if it is the proper type or not, so we patch setValue to include the value even it is not present on enum (instead drop the value).
    Typecast patch was extended to not modify the data only convert to proper type if possible, otherwise, keep the wrong value.

    The goal is allow the user see the wrong value with the error message.

See merge request nexedi/erp5!1902

by using str on a dict we don't produce consistent results depending
on hash randomization. This was visible with erp5_core_test:testCacheTool
and PYTHONHASHSEED 12 , the cache id generated in
https://lab.nexedi.com/nexedi/erp5/-/blob/a0aa9184d/bt5/erp5_core_test/TestTemplateItem/portal_components/test.erp5.testCacheTool.py#L216-218
was
"('py_script_obj', (60000,), {'result': 'a short value', 'portal_path': ('', 'erp5')})"

and the cache id generated in
https://lab.nexedi.com/nexedi/erp5/-/blob/a0aa9184d/bt5/erp5_core_test/TestTemplateItem/portal_components/test.erp5.testCacheTool.py#L239-241
with same arguments for delete was
 "('py_script_obj', (60000,), {'portal_path': ('', 'erp5'), 'result': 'a short value'})")

nowadays we can use time.sleep in restricted python

anyway, what happened is stored in the HTTP Exchange

this BT is to hold code and configuration related to the
Interface with DQE data quality services

  The administrator can enable it back clicking in a button,
  this can prevent massive email sending from unattended sites (development for example)
  related to test failures or average development

See merge request !1897

* change property drone_dict into function getDroneDict
* add timestamp to getCurrentPosition return value
* add timestamp to drone_info

in ec835d86 (payroll_l10n_fr: add missing sorts in DSN report, 2024-02-28)
we added sorts so that the report is deterministic when hash randomization
is enabled, but this was not enough, when iterating through employee_ctp
to find the social_contribution_organisation, not all records have a
corporate_registration_code, so we check that it's present before
accessing it.

Also, one `sorted` that was added was incorrect, because the elements
are dict, so they can not be compared on python3.

Instead of overriding the method and adjusting edit order in some class,
define "_default_edit_order" as a class value and use it in Base._edit
as default value when caller do not explicitly pass edit_order.

This was made to keep the default edit order consistent with the order
of edits on python2 for properties where the edit order matters.

This affects mostly scripts, when for example in a script we do:

  delivery.edit(start_date=d, stop_date=d)

on python2 without PYTHONHASHSEED, stop_date is also set, so we keep
this behavior (that is assumed by some tests).

We also change the order of edit for other properties not constraint
by edit_order to edit them in alphabetic order, to have a constant
deterministic behavior.
Co-authored-by: Kazuhiko SHIOZAKI <kazuhiko@nexedi.com>

Because this was using a set, the order in which property sheets were
used when generating classes was not deterministic.
This can make a different if two property sheets define the same
property. This was the case for short_title property, which was defined
with different default values in DublinCore and SimpleItem property
sheets. With this change the behavior is always same when hash
randomization is enabled.

Property sheets can be defined in classes or on the portal type. The
test only covers the case that a property defined on the portal type
must override the same property defined on a class, but the expected
behavior is also that property sheets defined on a class override
property sheets from parent class.