This is a workaround to bypass erp5_hal_json_style limitations: it is not possible to render a field in JSON by directly using it as a callable

This will prevent the input gadget to be changed if its parent call render with the same value (as ERP5 does in case of formulator error).

update_method has to be send

This avoids relying on implementation details by only relying on regular
API. This test should now be more robust in face of implementation changes.

Also, add an XXX about manage_test annoying behaviour.

Avoids the double-nonsense of looking the document up by path inside callee (!)
using the catalog (!!).
Also, follow naming conventions: variables containing documents should end
in _value, not in _object.

Vincent Pelletier:
- commit message
- remove unrelated change
- squash similar similar-intent commits even though they apply to
  different BTs

These methods must not be called synchronously:
- they can break catalog by not being careful enough about other
  reindexations which may happen in parallel. See the serialization_tag
  mechanism for more.
- indexation gets executed in the security context of the user causing the
  call, which may lead to an indexation result different from what happens
  when indexation happens with an all-accesses user.
These lines of code (some even commented-out) give a bad example. Replace
them with safe equivalents.

…r in (multi)relation field

/reviewed-on nexedi/erp5!556

Such tables are not visible in the ZMI (which is arguably a bug on its
own, although the ZMI is deprecated), but even accessing the setting
tab is broken as it runs these methods.
This change at least allows accessing stuff to start fixing.

The order in which messages are returned by getMessageList is undefined,
and manageInvoke refuses to execute messages which are blocked by their
dependencies. Notify depends on Alarm_runUpgrader, so it must be explicitly
ran second.
Also, avoid listing activities twice.

Here, we expect exactly two activities, one of each type, and just do not
rely on these being listed in any order (...in theory, as this is actually
assumed by the next iteration on getMessageList, but this is a separate
issues).