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

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: 5a0b3763 and 388a508b.


/reviewed-on !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.

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.

erp5_trade: Proxify my_ledger to Base_viewTradeFieldLibrary as it should have always been (06f701a4).

This fixes TestXHTML.test_configurationOfFieldLirary Unit Test failure:
  Assertionerror: 1 fields to modify
  erp5_trade/TradeModelPath_view/my_ledger: Unproxify Field

erp5_trade: my_ledger.items=Delivery_getLedgerItemList as all other erp5_trade my_ledger fields (06f701a4).