"immediate", in this context, means "during the same transaction".
Normally, indexation always happens in a transaction different from the
one which did the indexation-inducing action (modifying a property,
creating a document, explicitely requesting indexation). This is because
SQL and object databases do not have the same approach to conflict
resolution: in SQL, the last one wins, and ordering happens based on locks.
In ZODB, conflict resolution is stricter in that to modify an object
a transaction must have started with the same revision of that object as
the one which is current at the time it is trying to commit. As both
databases must be kept consistent, one interpretation must be enforced
onto the other: the ZODB interpretation. So delayed indexation, plus
careful activity sequencing (serialization_tag) is required.

But in very specific cases, it is actually safe to index a document
immediately: when creating that document. This is because the only
conflict which may then happen is if two transaction produce the same
path, and ZODB will prevent the transaction from committing altogether,
preventing any conflict resolution from happening. Pasting a document
falls into this category as well, for the same reason.

In turn, this feature removes the need to call "immediate" reindexation
methods, allowing to restrict their availability later and preventing
API misuse and catalog consistency compromission.

Two variants of "immediate" indexation are available:
- internal to the method which creates considered document
- delayed to a caller-controller, but mandatory, point later in current
  transaction, by using a context (in python sense) manager object.

Consistently with other methods which may trigger reindexations.

Consistently with newContent/constructInstance, caller may request one of
three choices:
- do not override class choice
- override class choice, making instance non-indexable
- override class choice, making instance indexable
So is_indexable now defaults to None instead of True.

Directly bind superclass callable instead when applicable.
Trivial python simplifications.
Assorted coding style improvements.
Drop unhelpful comments and docstrings.

erp5_l10n_fa is needed to test the RTL direction.

This is activated only for erp5_l10n_fa by adding the language direction on the body element.

Thanks to Ali Hallaji for the original work.

Otherwise, aq_chain looks like (note the Temporary Discussion Thread):
[
 <Discussion Post at /erp5/discussion_thread_module/1/2>,
 <Discussion Thread at /erp5/discussion_thread_module/1>,
 <Discussion Thread Module at /erp5/discussion_thread_module used for /erp5/web_site_module/km_test_web_site/forum/Thread-1-GAJgJcpBPJ>,
 <Temporary Discussion Thread at /erp5/web_site_module/km_test_web_site/forum/Thread-1-GAJgJcpBPJ>,
 <Web Section at /erp5/web_site_module/km_test_web_site/forum>,
 <Web Site at /erp5/web_site_module/km_test_web_site>,
 <Web Site Module at /erp5/web_site_module>,
 <ERP5Site at /erp5>,
 <Application at >,
 <ZPublisher.BaseRequest.RequestContainer object at 0x7f478aa18450>
]
which can confuse a "parent" walk.
Also, reuse existing code, related to asContext which is just what is
needed here.

erp5_real_time_inventory_accounting: Move Root Delivery Simulation Rule to test bt5 as it is only used in Unit Tests.

erp5_real_time_inventory_accounting: Matching on source_section is not enough (Automatic Delivery Accept Solver).

The getModuleItemList function should not cache absolute_url_path as it
may vary according to where the script is called from. Here we generate
the cache key to also vary according to the same condition as the module
absolute_url_path results.

_portal_url_  _________called_from_url_________ -> __portal_url_VirtualRootPhysicalPath___  ________module.absolute_url_path_______  _result_
/erp5         /erp5/...                            /erp5                                    /erp5/my_module                          OK
/erp5         /erp5/web_site_module/my_site/...    /erp5                                    /erp5/web_site_module/my_site/my_module  BAD
/erp5/        /erp5/web_site_module/my_site/...    /erp5/web_site_module/my_site            /erp5/web_site_module/my_site/my_module  OK

Sequential number generators stored in a fixed-size format eventually run
out of values. But activity queues only care about what activities are
currently present: any uid can be reused as soon as it is available.
So stop using a sequential id generator for activity uids, and instead use
random values.

Vincent Pelletier:
- Commit message.
- Minor formatting changes.
- Do probability computations, and increase activity uid storage size to
  64bits integers, up from 32. Table schema migration happens on first
  activity node which starts on upgraded code.
- Apply to SQLJobLib too.

Duplicate message detection is not good enough: different messages with
the same unicity value may bear different serialization_tags. This code
does not takes this into account, which can lead to deleting such tagged
message and validate an untagged one, which breaks serialization_tag
contract of preventing any further activity validation until execution
of all such-tagged validated activities is successful.
Also, it is not validation's node job to deduplicate: it can happen during
message execution without slowing down this crucial (performance-wise)
activity node.
As a result, distribute methods of SQLDict and SQLQueue can be factorised.

0. Download codemirror tarball ('lib/codemirror.js' is not available in git repository anymore):
   wget http://codemirror.net/codemirror.zip && unzip codemirror.zip

1. Prepare files to upload:
   cd UNZIPPED_CODEMIRROR_DIRECTORY/
   rm -r bin/ doc/ index.html demo/ src/ test/ rollup.config.js package.json mode/*/index.html mode/index.html .[a-z]*
   # 54087b03
   mv addon/edit/ addon/cm_edit/ && find -type f | xargs sed -i 's#addon/edit/#addon/cm_edit/#g'
   # https://github.com/codemirror/CodeMirror/issues/5321
   sed -i '/"Ctrl-V"/d' keymap/emacs.js

2. Edit zope.conf to enable FTP access:
   <ftp-server>
    address localhost:2202
   </ftp-server>

3. Upload files to Zope:
   yafc ftp://zope:zope@localhost:2202/erp5/portal_skins/erp5_code_mirror/codemirror/
   yafc> rm -r *
   yafc> put -r *

4. Run portal_alarms/Alarm_checkSkinCacheActive?fixit:int=1

- requests to bootstrap and site availability urls using a script run with userhosts
- hardcoded parameters removed
- try-exception controls in communication with master
- general refactoring and cleanup

ZODB Components not following ID=(document|extension|test).VERSION.REFERENCE convention are not importable anymore.

Import mechanism now relies on this convention to find the document in
portal_components.

This is necessary to get rid of _registry_dict (ZODB Components equivalent of
document_class_registry), along with several locks. This used to be a mapping
between (reference, version) to ID stored outside of Zope Transactions as a
dict on global erp5.component.XXX modules.

This did not work for long transactions such as installing many bt5s:
  1. Transaction1: Install a bt5 with ZODB Component "Foo".
     => Trigger a reset and _registry_dict is cleared.
  2. Transaction2: TimerServer kicks in.
     => Generate _registry_dict without "Foo".
  3. Transaction1: Install another bt5 using "Foo".
     => "Foo" not in _registry_dict and thus considered not present.

/reviewed-on !613

- test duration is get from testsuite definition
- refactoring and cleanup in runScalabilityTestSuite and benchmark
- request timeout in metric thread

/reviewed-on !607

Document why this method tolerates unhandled method types.

workflow_history attribute may not exist on bootstrapping (constructInstance),
which leads AttributeError exception, which could have further side-effects
as this is called during dynamic class initialisation.
Also, original code from CMFCore.WorkflowTool, from which this code is
derived for bootstrap reasons, catches KeyError (when history exists,
just not for considered workflow), so follow the same pattern.
Laslty, also catch IndexError in case the workflow history entry would
exist empty - which would be the sign of a broken workflow history.

workflow_history attribute may not exist on bootstrapping (constructInstance),
which could lead to acquisition, which could have further side-effects
as this is called during dynamic class initialisation.
Also, original code from CMFCore.WorkflowTool, from which this code is
derived for bootstrap reasons, does the equivalent aq_base, so follow
the same pattern.

LIMIT hides duplicates. We want to know if we ever violate the
soft-constraint of path unicity in catalog, so stop setting a LIMIT.
Also, for uid lookup, LIMIT is meaningless as this is ha hard unicity
constraint (must be enforced by relational database for ERP5 to work).

Also, simplify both the DTML and the SQL by having fewer ways to be
invoked (backward-compatible).

When _reindexObjectList receives a document more than once (which may
happen when multiple different-tag indexation activities are spawned for
the same document), it would emit a meaningless error, saying that
document /foo/bar stole the uid of document /foo/bar.
Instead, fix duplicate tracking and skip such dulicates.

Also, simplify & make _reindexObjectList more robust:
- Always check path length.
- Allocate uids before looking for duplicates in catalog (it may not be
  actually needed at this level nowadays).
- Always check both uid-to-path and path-to-uid mappings.
- Reuse existing mappings to detect duplicates among objects being reindexed,
  removing the need for assigned_uid_dict.
- Avoid computing path more than once, as it's expensive.

ZSQLCatalog now requires having portal_ids.
Keep support for clearing existing ones.

Any existing "reserved" row encountered while indexing documents will be
treated as a uid being attributed to more than one path.

See nexedi/erp5@78356c43

TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types