See merge request nexedi/erp5!1814

See merge request !1817
Fix loitering trajectory when the drone is closer to the center than the required radius.

<dtml-sqlvar "None" type=string> should be 'null', not 'None'.

When using the public API of pandas (which is partially allowed in
restricted python), it can happen that this public API raises the error
'pytz.NonExistentTimeError' [1]. Users should be allowed to
import and therefore catch this exception.

Before this patch we could only do:

>>> try:
...   ts.tz_localize(tz)
... except Exception:
...   ...

After this patch we can do;

>>> try:
...   ts.tz_localize(tz)
... except pytz.NonExistentTimeError:
...   ...

pytz delivers more exceptions which are all equally harmless.
We can therefore in the same patch also allow them, as they may be
useful for similar cases.

This patch also comes with tests which ensure that the allowed
exceptions can be imported into restricted python and also a
test to ensure no other objects in the pytz namespace can be used.

---

[1] https://pandas.pydata.org/pandas-docs/version/2.0.3/reference/api/pandas.Series.tz_localize.html

/reviewed-by @jerome
/reviewed-on !1802

When an activity failure happens, the SQL row is updated:
- date is set to a future value, so the activity does not get retried
  immediately, in the expectation that what caused the failure may have
  cleared by that point.
- retry is incremented, to allow limiting the total number of retries
- priority is incremented

This last point seems harder to justify, and seems redundant with the date
increase. In the context of processing node families and with a steady
influx of similar activities at a base priority level, such priority
increment can postpone the victim activity execution to an arbitrarily
large amount of time, which is undesirable.
So, remove this increment.

See merge request !1809

   The implementation only works with ERP5 Login, since it is the only portal type that
   holds password in ERP5. Other implementations are password-less: Certificate Login,
   Google Login and Facebook Login, so they cannot have their password reset anyway.

   It is overkill split the login on multiple categorization, to use some portal group (ie:
   getPortalLoginPortalTypeThatCanResetPassord...) until we have a a clear usecase.