This test case tries to provide message helpful for debugging in case
of assertion failure for assertUserCanPassWorkflowTransition, but
this was not correctly using new workflow API and in case of failure
there was an error like this:

  File ".../custom/test.py"
    self.assertUserCanPassWorkflowTransition(user, 'stop_action', packing_list)
  File "product/ERP5Type/tests/SecurityTestCase.py", line 237, in failUnlessUserCanPassWorkflowTransition
    if wf_transition.trigger_type == TRIGGER_USER_ACTION:
AttributeError: 'NoneType' object has no attribute 'trigger_type'

The previous implementation was using getGuardSummary, which no
longer exist in new workflow, so we implement similar logic here.

The new message changes a bit, it now look like this:

    AssertionError: User X can NOT pass stop_action transition on Internal Packing List at /erp5/internal_packing_list_module/20220218-22A38 (draft on delivery_causality_workflow, draft on internal_packing_list_notification_workflow, started on packing_list_workflow).
     Roles: [Owner, Member, Authenticated, Associate]
     Available transitions:
              deliver_action[packing_list_workflow]
                    Expression:
                    Permissions:
                    Groups:
            * stop_action[packing_list_workflow]
                    Expression: python: not(state_change['object'].getPortalType() == "Sale Packing List" and state_change['object'].getSimulationState() == "confirmed")
                    Permissions:
                    Groups:

1b1dbf60 (tests: also consider python unittest failures in
functional tests, 2021-06-16) was not counting properly the cases
where we have selenium failures. In that case we only want to count
selenium failures, if we add with the python failures from
status_dict, we report one extra failures.

The correct approach is to count selenium failures if any and otherwise
count python failures
Co-authored-by: Vincent Pelletier <vincent@nexedi.com>

Avoids duplicating items from that list.

Both so that changes to the list of core business templates are applied on
upgrade, and to avoid uninstalling core business templates, if no other
maintained-up-to-date business templates depend on them.
Also, improve the documentation of the erp5_upgrader version of this
script.

But make it non-publishable.

The main reason is to use portal type setters, and not set the properties
directly: setting the properties directly bypasses interactions which
trigger type refresh, which hence prevents such changes from being applied
to the types until something else would cause a reload.
While at it:
- modify the property sheet list once only instead of once per added
  property sheet
- only modify the property sheet list when fixit is true
- improve constraint message to actually tell what is being detected
- do not report a constraint error when no change is necessary
- follow naming conventions: avoid abbreviations, variables holding
  documents must end in "_value"
- avoid single-use local variables

This reverts commit 77b3f202.
For some obscure reason, this affects unit tests related to inventory
unit conversion. There seems to be too much code to cleanup to keep this
patch for now, so drop it.

Fallback to modification_date if a document does not have an effective_date.

Indexation activities may spawn further activities, and for_each_activity
expects the number of activities after a test to be zero.

System user should be more reliable than whatever user has ownership of
catalog tool (which may have its account closed or its roles changed).

CMFActivity: Fix ActivityRuntimeEnvironment.getPriority when activity was not loaded from an SQL queue.

This happens when activities are being flushed from the ActivityBuffer
directly, without being inserted into and then loaded from the SQL queue.
It is unclear whether there are uses of this pattern besides
testCMFActivity, but it is easy enough to fix.

Checking activity presence/absence is not enough: it risks both false
negatives and false positives. Instead, manually poison the catalog's
content and check which value we retrieve after executing spawned
activities (if any).

it's not finished, rework if need

- Remove trailing whitespaces
- Follow guidelines
- Fixup types

Also, use it in Products.ERP5Type.tests.ERP5TypeTestCase.

The only use 'my_' has above 'your_' is to provide a default field value
without needing a TALES expression. This only gets applied based on the
field ID in the form being rendered. Field libraries are never meant to be
rendered, so using 'my_' is always (if harmless) pointless. What really
matters for the field naming convention (which exist to avoid collisions
with form properties) is that *some* prefix is used, be it 'my_' or
'your_'.
So update this check rule to tolerate 'your_' prefixes in addition to
'my_'.
Also, use 'not any([...])' instead of 'not 1 in [...]'.

I guess this is the intention of the unnecessary pair or parentheses.

"Certificate Authority" is a bit long, especially as it is often followed
by some other word ("Certificate", ...).

Abbreviations must be upper-case.

The precise number of entries in a bucket depend on an estimation of the
size of a pickle. The pickled data contains DateTime objects, making an
equality test brittle:
- DateTime's timezones are stored as strings (ex: 'GMT') whose length
  depend on Zope's timezone, which is variable
- DateTime's time is stored as a floating-point value represented as a
  string whose length depends on the number of units and decimals are
  necessary to represent its value, both being variable (one based on when
  the test was run, the other based on clock precision and exact test
  execution timing)
Instead, restore the originally-considered-acceptable boundary (24) and
verify that the generated value is greater or equal to it.
If 24 is considered too small to be acceptable, then it is a decision
independent from the present change.

See merge request !1553

Some combinations of periodicity, for example repeat every first week
of the year and every month February are impossible (because the first
week of the year is always in January) and such configurations caused
infinite loops or probably overflow if we wait long enough.

The algorithm being to try the next day until all constraints are met,
it is not guaranteed to terminate.

To make sure the algorithm terminate, we rely on the fact that calendars
repeat after some time, so if after a few years we did not find a
matching combination, we can stop retrying.

according to https://en.wikipedia.org/wiki/Determination_of_the_day_of_the_week

> Each leap year repeats once every 28 years, and every common year
> repeats once every 6 years and twice every 11 years.

so trying for 28 years should be enough to see all combinations

In ZODB 5, with commit b6ac40f1 (Uses an unwrapped transaction manager,
2018-10-14) the transaction is bound to the thread opening the
connection.
The previous pattern of opening transaction in the main thread and
passing the already-open connection to the working thread caused the
working thread connection to be managed by the main thread connection
and in ZODB 5 cause the test to block.

Fix this by passing a connection factory method and opening
connection in working thread.
Also simplify closing of connection by using a closing context manager.

With upcoming ZODB 5, oids (used as persistent references in pickles)
are no longer str as it use to be with ZODB 4, but instances of
zodbpickle.binary, which with zodbpickle 1 are a subclass of str on
python2.

OrderedPickler was a subclass of pickle.Pickler, the pickler from standard
library, but this pickler was not able to use a str subclass for persistent
references, when pickles are loaded with noload method, persistent_load
is called with `None` instead of the actual string subclass instance.
This was problematic in the XMLExportImport handling of business templates,
because ZODB.serialize.referencesf was unable to find persistent references.
The error was:

    ZODB-5.6.0-py2.7.egg/ZODB/serialize.py", line 664, in referencesf
        assert isinstance(reference, list)
    AssertionError

because the reference was None.

zodbpickle 2 changed to make zodbpickle.binary implemented in C, which
was failing earlier, because pickle.Pickle can not pickle these objects,
failing in an error like this:

    lib/python2.7/copy_reg.py", line 70, in _reduce_ex
        raise TypeError, "can't pickle %s objects" % base.__name__
    TypeError: can't pickle binary objects

This change also simplify our own implementation, by dropping jython
support and calling save_dict on the super class instead of copying the
implementation.

Further references:

- minimal script to reproduce the issues:

```python
from __future__ import print_function
import io
import pickle

import zodbpickle
import zodbpickle.pickle
import zodbpickle.fastpickle

class ExternalObject(object):
  def __init__(self, oid):
    self.oid = oid

def persistent_id(obj):
  if isinstance(obj, ExternalObject):
    return obj.oid

def persistent_load(persid):
  print('persistent_load called with persid', repr(persid))

o = ExternalObject(oid=zodbpickle.binary("binary persid"))

for pickler_class in pickle.Pickler, zodbpickle.pickle.Pickler:

  f = io.BytesIO()
  p = pickler_class(f, 1)
  p.persistent_id = persistent_id
  p.dump(o)

  print('dump with pickler %s:\n  %r' % (pickler_class, f.getvalue()))

  # ZODB uses this unpickler
  up = zodbpickle.fastpickle.Unpickler(io.BytesIO(f.getvalue()))
  up.persistent_load = persistent_load
  up.noload()
```

```console
$ python2 repro.py # with zodbpickle 1
dump with pickler pickle.Pickler:
  'ccopy_reg\n_reconstructor\nq\x00(czodbpickle\nbinary\nq\x01c__builtin__\nstr\nq\x02U\rbinary persidq\x03tq\x04Rq\x05Q.'
persistent_load called with persid None
dump with pickler zodbpickle.pickle_2.Pickler:
  'U\rbinary persidq\x00Q.'
persistent_load called with persid 'binary persid'
```

```console
$ python2 repro.py # with zodbpickle 2
Traceback (most recent call last):
  File "repro.py", line 45, in <module>
    p.dump(o)
  File ".../lib/python2.7/pickle.py", line 224, in dump
    self.save(obj)
  File ".../lib/python2.7/pickle.py", line 273, in save
    self.save_pers(pid)
  File ".../lib/python2.7/pickle.py", line 340, in save_pers
    self.save(pid)
  File ".../lib/python2.7/pickle.py", line 306, in save
    rv = reduce(self.proto)
  File ".../lib/python2.7/copy_reg.py", line 70, in _reduce_ex
    raise TypeError, "can't pickle %s objects" % base.__name__
TypeError: can't pickle binary objects
```

* ZODB change starting to use zodbpickle.binary instead of str:
12ee41c4 (-ZODB now uses pickle protocol 3 for both Python 2 and Python 3., 2018-03-26)
Since of 5.4.0 release

* zodbpickle change starting to use C objects for zodbpickle.binary:
bbef98c (Implement zodbpickle.binary in C for Py27., 2019-11-12)
Since of 2.0.0 release

Now that we fail immediately in case of failure, the deadline can be
safely increased, because it only protects against kind of infinite loops.

Increasing the delay should fix RuntimeError: tic is looping forever
errors with only messages in status -1, that we sometimes saw on testnodes.