patches/DCWorkflow: use 'user/getIdOrUserName' as workflow actor expression instead of 'user/getId'.

so that ID is used for ERP5 user case, that should never change, and User Name is used for system users
like Anonymous User or System Processes, without changing all workflow definitions.

so that getId() is used for ERP5 users and getUserName() is used for special users
like Anonyous User or System Processes whose id is None.

To prepare for moving user id to a different property.
Mostly replacing getReference on Persons with Person_getUserId, and
catalog searches with PAS API when it is meant to search for a user and
not really a person by reference.

Because unit tests were used to choosing a login and setting a password,
making them use such method seems easier than adapting them to use the
existing "login" method, which really works by user id and not by login.

use getId() instead of getUserName() where user is supposed to be neither Anonyous User nor System Processes.

Apply security in ERP5User methods.

Require the findings to be consistent when applicable.
May happen for example when migrating a user from being handled by one PAS
plugin to another.

It does not depend on a specific plugin.
Also, update all importers.
Also, reduce import cycles in ERP5Security.

The value used to be displayed will be the last value of the tuple

This is "Internal Trade Condition", not "Purchase Trade Condition"

acl_users ERP5 user enumeration plugin(s) already search for Persons by
their user id, so this code duplicates the checks done just a few lines
above it.

Rather than testing before calling.

acl_users is one of the rare objects (with SQL connectors) which are
intended to be fetched by acquisition, allowing overrides.
Also, move code out of try..finally block where possible.

@seb I need this for a wendelin project, but I think it is usefull in generic erp5, is it ok ?

/reviewed-on nexedi/erp5!203