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 !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.

Use the filter editor to select the domain in a select input.
This concentrate all search parameters in only place to improve the usability and discovery.