If the user wants actitivites, it should create multiples StandardBT5ConfiguratorItems,
  This should accellerate Tests based on ERP5Configurator.

  This should be recoded, but it should speed up bootstrap of a site,
  as get modified objects are not called.

It the user don't have fully permission on the object (already changed state), this set will fail to check if source should be defined.

  The upgrade ordering seems buggy and requires to force reinstall it

This allow during a subscription process, create a user and them create all
documents using that user w/o rely on proxy roles (keeping good ownership
across the documents).

Without this (on slapos master ui) the redirection places value unquoted causing parser to fail later on when resolve {n.me}

  The user can be present from diferent logins, password tool only works with ERP5LoginUserMager
  users.

Returning true allows to add movements to existing one, and this group shall
always separate them.

If 2 lines have the same effective date (catalog has a 1 second precision),
always return the validate and open first.

Commit: 02d06501

Changes applied from history:

http://git.erp5.org/gitweb/erp5.git/history/refs/heads/interaction-drop:/product/ERP5/Document/SubscriptionItem.py?js=1

Original commit from : Lukasz Nowak <luke@nexedi.com>
                       3e45ec35

Conflicts:
	bt5/erp5_crm/bt/revision

See merge request nexedi/erp5!1732

See merge request nexedi/erp5!1731

cause by nexedi/erp5!1726

On the way to Zope 4, the biggest change was DateTime >= 3, which has these main differences:

 - `DateTime` instances are new style classes
 - `DateTime.__eq__` now take into the timezone into account
 - `DateTime` supports timezone naive ( https://docs.python.org/3/library/datetime.html#aware-and-naive-objects ) - actually this is since DateTime 2.12 , but since we fully patched the method where the parsing happens, ERP5's patched DateTime never used timezone naive dates.
 - pickles are also different.

These are changes to prepare ERP5 code base to support DateTime >= 3, while keeping compatibility with the previous behavior, this means that we keep patching to keep the same behavior as DateTime 2, so that `DateTime.__eq__` ignores timezone difference and `DateTime` does not support timezone naive dates - these two different behavior seemed to introduce too much breakages, especially in project code, with no immediate benefit for our usages. For now, while ERP5 is still based on Zope 2 / DateTime 2 the fact that DateTime are new style classes has no impact, this will only impact once we switch to Zope 4.

This also change the code to adjust the part where we were depending on implementation details of DateTime and where the details changed on DateTime 3, sometimes exposing higher level API, like the new `timeZoneContext` to use in tests.



See merge request nexedi/erp5!1593

See merge request !1725

See merge request nexedi/erp5!1726

use calendar module and public DateTime API instead.

This ensures that we don't break more.

We have code depending on these attributes, they were used in pattern
like this:

```py
try:
  DateTime(user_input)
except DateTime.DateError:
  error("invalid date")
```

so it's safer to keep the attributes for now, since we are already
patching a lot

We have too much code depending on this behavior, so we keep this patch
for now.

By using iso format we create dates in UTC timezone

This is a context manager which temporary allow to change the time zone.

It is not thread safe and intended to be used in tests only, to replace
setTimeZoneToUTC and setTimezone methods by something unified which
makes the transition to DateTime 4 easier, because changing timezone
was done by patching private attributes and the DateTime 4 use different
attributes.

Use calendar module instead. These API depends on current locale, but
we don't set the locale in ERP5, so these remain in English

This is just hiding problem and does not seem needed.