The original need to touch this comment is that it mentions now-removed
Folder_reindexObjectList script. But also:
- it mentions multi-ZEO setups, which are now discouraged if favour of
  using NEO
- it mentions pre-conceived optimisations, which can be wrong and hence
  misleading (up-to-date measures are needed before deciding what to
  optimise)
- it mentions a number of activity nodes which is nowadays exceeded
  without seeing any obvious issue caused by activity table deadlocks
  (which are nevertheless still likely an issue, just not yet breaking
  scalability)

These are now superseded by recursiveReindexObject.

This method does not belong to Folder (nor Base, even as an alias), as
it recurses wihout any limit in a tree whose node count is unknown.
Such generic recursion should either be deferred (split in multiple
transactions, each processing a limited chunk of the tree) or not be
recursive (which of course depends on the need).
There is a single caller left (constructInstance) where the subtree size
is assumed to be reasonable, as it was constructed inside current
transaction. So essentially rename this method so it is only used in such
conditions.

isAncestryIndexable is a parent-recursive version of isIndexable: it
will return False if any parent is non-indeable. This simplifies
disabling indexation of an entire tree, from its root to its deepest
leaves.
isSubtreeIndexable allows preventing any subobject from being indexable,
without having to mark each individual subobject as non-indexable. This
is different from isAncestryIndexable, as it allows having an indexable
root, but no children indexable. This is especially useful for Trash Bins,
where the bin itself should be indexable (because there is no reason not to)
but its content must not be indexed, while being left as it was found in its
original location.

Should make Folder_reindexAll and most custom indexation methods obsolete.
Remaining valid reindexation methods are:
- reindexObject: for a single document, which may contain subdocuments
  which indexation is not necessary
- recursiveReindexobject: for any subtree of documents
- ERP5Site_reindexAll: for site-wide reindexations, as there is a semantic-
  dependent indexation order.

Also, uniformise and factorise spawning immediateReindexObject.

Also:
- testSupply: Drop check for the previous magic threshold.
  _recurseCallMethod takes care of it all now.
- testXMLMatrix: Let activities execute before changing cell id.
  This works only because recursiveReindexObject on the matrix spawns a
  single recursiveImmediateReindexObject activity on that context. Now,
  up to 1k immediateReindexObject activities (for the first 1k sub-objects)
  are spawned immediately, preventing their renaming immediately after
  commit.
  So let test wait for indexation before trying to rename.
- testERP5Security: More activities are now spawned immediately, adapt.

after_method_id is too aggressive a dependency.
after_path_and_method_id is marginally better, but is bad practice
nevertheless, as such activity dependencies remain very hard to introspect.
Tags allow more variations, and are hence easier to follow.
Also, add XXX comments when (recursive) reindexation is only added to
represent the dependency, without certainty that a reindexation is actually
needed per-se: maybe another place in the code chould just appropriately
tag its reindexation activities instead, saving at least the cost of
spawning one more activity set, and at most the cost of actually
reindexing these documents.

Also, drop isIndexable instance property, unmasking class property, which
already has the value we need.
Also, factorise catalog clearing by reusing ERP5Site_reindexAll's.

Allows having a more consistent API between this tool and all other
Nexedi-maintained tools.

Reduces code duplication.

portal_activities contains documents which need to be (and are) indexed.
For consistency, the tool itself should be indexable.

So it is not just an unused constant (OFS_HANDLER) and no implementation.

Also, clarify what exactly was the broken BTree marker value, fixing
isBTree accessor. Update associated tests.

erp5.util.testbrowser: Refactor of openNoVisit() and {Image,Submit}Control for recent zope.testbrowser (followup of 5a0b3763).

And specifically, Domains (more portal types may be added to the relation
string field widget as needed).
Predicates get expanded to the list of documents they match.

Can be used to identify whether a document should be used to match other
documents, rather than as a final document itself.

Reorganize code by parsing the appcache with jio.

Interface checking is done by a standalone gadget whch directly display the status.

Drop not needed code (do not reimplement getInterfaceList for example).

Force interface strict HTML format

/reviewed-on nexedi/erp5!706

/reviewed-on nexedi/erp5!705

Send 'on' value when checked.
Do not add checkbox in the request body if unchecked.

for example: SSLError: ('The read operation timed out',)

/reviewed-on nexedi/erp5!703

erp5.util.testbrowser: Require zope.testbrowser >= 5.0.0 since 5a0b3763 so update dependency accordingly.

Otherwise, the query will include a pointless "node.uid > 0" condition
(because internal API has no choice but to return a condition) which
confuses the query optimiser and may lead to very suboptimal execution
plans: a range scan of node.uid (catalog as node, node.uid=stock.node_uid)
despite provided account uid list constraining stock.node_uid.

Remove trailing whitespaces.
Make it easier to extend the list of indexed columns without causing
unnecessary diffs (sadly, SQL being SQL, those lines will still cause
extra diffs).

/reviewed-on nexedi/erp5!699

This Merge Request adds ```reachability_workflow``` and adds it to all Coordinate types  (Adress, Email etc.)
so that the can be marked as ```reachable``` or ```unreachable```.
It also adds ```coordinate_interaction_workflow```, so that when a coordinate text changes actions can be triggered.
The default behaviour is that, when coordinate text changes for an 'unreachable' Coordinate, it is marked as reachable.

We already discussed this with @jerome , but I cc @nexedi , since this can break compatibility in projects, because
in the past Coordinates acquired ```validation_state``` by their parent document (Person, Organisation, etc).
So now, if some code checks ```getValidationState``` (though it should be checking on the parent) for Coordinate, or searches Catalog with ```validation_state``` (though it should be ```parent_validation_state```), behaviour will change.

Test Result <a href="https://nexedijs.erp5.net/#/test_result_module/20180608-2D68AF16">here</a> seems good (3 failures in UI tests that seem unrelated)


/reviewed-on nexedi/erp5!691