Persons created before the introduction of ERP5 Login and user_id will only
have a user_id after migration if they were already user before migration,
otherwise they will not have a user_id and creating assignments and ERP5 Login
for this person creates a user which can not log in the system.

To make it possible for these persons to login anyway, we ensure person has a
user id when validating a login

while setting an initial user id should be allowed for any user which can
create a person, changing an already set user id can have security
implications, so we protect it with a more strict permission

user_id are technical things that should not be displayed to users.

In the case of tokens, for now we show "something that's not user id / not the
token secret". That's not ideal but as far as I know whe don't really have use
cases of tokens to show a page where user caption would be displayed.

Person.setUserId is heavy, it serializes person module to prevent concurrency,
but in some cases we the risk of having duplicate user ids is under control, so
we don't want to pay the performance price.

See merge request !1242

See merge request !1243

padding too much in buttom make header bigger, so when export to pdf, header is cut off to hit heigth which make logo display at top

also needs to be declared in hidden content types to prevent adding
directly in preferences

This activity is spawned on all nodes, which cause too many conflicts.
We can take the risk here, assuming that references were already OK
before migration.

Person.setUserId does expensive checks to ensure that user ids are
uniques, but the default id generator already guarantees unicity, so
when default id generator is used we don't need Person.setUserId unicity
checks.

Now when generating user ids, we only consider user id conflict with existing
users, because it's not so expensive and might still happen, for example if
user ids have been migrated from person references when erp5_users PAS plugin
was used.
person.setUserId still performs the expensive checks to prevent duplications
against other transactions using person.setUserId, but not against other
transactions using person.initUserId

should be same for cases where type based method is a python script, but
is a bit more explicit/safe and consistent with other usages.

In 93e30e5e (Person: Store user id in new user_id property., 2016-12-09)
we adapted this test to the new behavior: title fallback to user_id or
id, but since persons always have a user_id by default, this test was
changed to check that title fallbacks to user_id, but the name of the
test still mention "fallback to id" which became a bit different from
what was tested here.

Revert testEmptyTitleFallbackOnId to check that title fallbacks on id,
using persons without user id and introduce new
testEmptyTitleFallbackOnUserId to describe the new behaviour with user
id.

See merge request !1244

See merge request nexedi/erp5!1241

See merge request nexedi/erp5!1239