This patch is specifically for the WWM/wind project. It unconditionally
sets the soft limit of open file descriptors to the hard limit. It is
'unconditionally' in two meanings:

1. Always set it and don't depend on instance configuration (via
   'instance.json). We certainly want this in the WWM/wind instance and
   adding the option to SlapOS would lead to a lot of copy-pasted SlapOS
   instance files in the WWM project, which are noisy, difficult to
   maintain and tedious to create.

2. Always set it and don't depend on the used server (Medusa or WSGI).
   In the upstream patches nexedi/erp5@39369169
   and nexedi/erp5@c42c1d38
   the option is only made available when using WSGI. But in our production
   instance we may want to switch back to ZServer/Medusa, which is why
   we need an ERP5 which supports the option independent from the used
   server.

In nexedi/erp5@39369169 the new option
'nofile' was added to set the soft limit of open file descriptors to its hard limit.
In nexedi/slapos!1451 (comment 193296) it was criticized that
the name of the option - 'nofile' - is too vague and in nexedi/slapos!1465 a new
name for the option was searched. Finally we agreed on the more explicit 'with-max-rlimit-nofile'.

The default soft limit of open file descriptors is usually set to 1024
in order to avoid breaking old software which still uses select. In many
projects we may need a higher limit: particularly in Wendelin based
projects we easily reach this limit. Before this patch it was therefore
necessary to either patch ERP5 in the project specific SR or to manually
increase the limit of the zope processes (or the parent supervisor) with
a tool like prlimit [1]. With this patch it becomes possible to increase the
soft limit to the hard limit with a command line argument of the zopewsgi bin.
This simplifies setting the soft limit for any Wendelin project.

[1] https://man7.org/linux/man-pages/man1/prlimit.1.html

/reviewed-by @vpelletier, @jerome
/reviewed-on nexedi/erp5!1827

---

NOTE wind commit:

We cherry-pick commit nexedi/erp5@39369169
for Mic.Wind, to automatically avoid the open file descriptors limit
issue.

With a254bf50 we
migrated most of np related security code from Wendelin to ERP5, we only
missed few lines. This patch moves the remaining lines to ERP5 so
that all numpy related restricted python code is at one place and no
longer scattered at two different repos/files.

tested at: https://erp5js.nexedi.net/#/test_result_module/20230302-F5352509

See merge request !1746

This makes it easier to test this API ( see testSlapOSPayzenWorkflow
from slapos.core )

fcd26be0 (CMFActivity,syncml: stop using a dedicated log file,
2023-02-17) introduced a regression in test and left an unused variable.

Pandas 0.20.0 introduced a bug fix [1] which changed the behaviour of
'DataFrame.to_records()', so that the resulting Record objects dtype names are
unicodes if the data frames column names were unicode. Before this bug fix
the dtype names were str, no matter whether the column names were str or unicode.

Unfortunately np unpickle breaks if dtype names are unicode [2]. Since
many of our data frame columns are unicode, loading arrays often
fails. In python3 this isn't a problem anymore, so until then we fix
this by introducing a simple monkey patch to pandas, which basically
reverts the mentioned bug fix.

[1] https://github.com/pandas-dev/pandas/issues/11879
[2] Small example to reproduce this error:

''
import os

import numpy as np
import pandas as pd

r = pd.DataFrame({u'A':[1,2,3]}).to_records()
a = np.ndarray(shape=r.shape, dtype=r.dtype.fields)
p = "t"

try:
  os.remove(p)
except:
  pass

with open(p, 'wb') as f:
  np.save(f, a)
with open(p, 'rb') as f:
  np.load(f)
''

/reviewed-on !1738
/reviewed-by @jerome @klaus

Add test which verifies that we can un/pickle 'pd.DataFrame' which were
converted to 'np.recarray' via the '.to_records()' method.

This test is necessary because it turns out that the combination of
pandas >= 0.20.x + python2 doesn't support this functionality by
default if the data frames column names are unicodes.

Please see !1738 (comment 179298) for
additional context.

/reviewed-on !1738
/reviewed-by @jerome @klaus

There are newer pandas versions which still support python2. The latest
one which still supports py2 (0.24.x) has initially been released in 2019
and should therefore be quite stable and better supported. We should
therefore prepare ERP5 so that it support those newer versions.

This patch mostly fixes movements within the internal pandas structure.
The patch still supports old object locations of previous pandas versions.

/reviewed-on !1738
/reviewed-by @jerome @klaus

We already use '.resample.mean()' in some projects.

/reviewed-on nexedi/erp5!1738
/reviewed-by @jerome @klaus

In some projects we use pandas resampler inside 'portal_callables'
(so with restricted Python). But we miss tests which check
whether pandas resamplers are allowed inside the restricted Python.
Due to this lack of tests we won't notice whether the usage of pandas
resamplers still work with a newer pandas version. With this patch
we can recognize if an internal change of pandas makes the resampler unusuable
in restricted Python.

/reviewed-on nexedi/erp5!1738
/reviewed-by @jerome @klaus

see b6dcbc19 (l10n_fr,l10n_jp: Fix translation of "Open", 2021-04-30)

This was old compatibility code

$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 nexedi/erp5!1745

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