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

- bug fixing while getting instance_guid
- minotr refactoring in request parameters

on PostModule_createHTMLPostForSupportRequest

instead of PostModule_getAscendingRelatedPostListAsJson

split SupportRequest_getSupportTypeList with another script called
SupportRequest_getSupportTypeListFromProjectValue

Prevent failure when opening the submit support request form.
If the first project has no related sale supply, the form rendering
was failing.

- testnode saves in its config the repositories paths
- minor refactoring and cleanup

/reviewed-on nexedi/erp5!606

Small recent change to handle cookies in connections to frontend urls.
* The refactoring of old testbrowser version was already reviewed and merge to master: nexedi/erp5@5a0b3763 and nexedi/erp5@388a508b.


/reviewed-on nexedi/erp5!587

- Thread classes to run commands and collect metrics for tests.
- Refactoring in benchmark process and result

/reviewed-on nexedi/erp5!588

- the commands to run the tests are launched using threads
- a thread is used to ask instance for metrics periodically
- refactoring for a more generic code
- refactoring in log handling
- old code related to created documents and create users removed
- new script parameters
- general refactoring and cleanup

- hardcoded software release url removed (http with password protection for now)
- scalability runner handles frontend request. It asks for a local master frontend apache software installation and instance request.
- testsuite brings the urls corresponding to instance, bootstrap, metrics collection.
- vinculation between scalability runner and runScalability script. Process manager is used to run the script as a command.
- scalability runner manages the test result cases and loops among different testsuite configurations.
- userhosts software is used to run the command for the runScalability script, to solve DNS.
- refactoring according to last changes in TaskDistribution
- general refactoring and cleanup

- communicator considers requests of master frontend and instance destruction.
- communicator retrieves frontend related information from instances.
- minor refactoring and code cleanup.