If Test Result is associated with Test Node and thus distributor, and
distributor defines process timeout use this timeout to now when to
restart test lines. This is useful to avoid needless restart of tests
running on nodes related to long time outing distributors.

Otherwise fallback to default.

This link allows to navigate from Test Result via its Test Result Node
to Test Node and distributor related to given Test Result.

Note: It happens only, if client will do subscribeNode before calling
createTestResult.

This is accompanying commit to "erp5_test_result: stop affecting last
remaining tests to all test nodes", where alarms redrafts running tests
for long running nodes.

In case of very long running test nodes, to which support is introduced
in this work, it is acceptable situation that test will get redrafted
and shall be stopped.

Unfinished test
(test_18_checkConfigurationGenerationERP5ScalabilityDistributor) uses
return value of subscribeNode and assumes it is ERP5 object.

This work changes return value of subscribeNode to JSON object,
following startTestSuite return value, thus rendering this test failure.

As test is unfinished, non asserting part has been commented out.

Also if process_timeout is available in received configuration setup
process_manager with transmitted value.

Backward compatibility is assured, that if no process_timeout is
provided, nothing is being updated.

Also process_timeout not set on master (the default), will not change
local default.

Extend subscribeNode to send configuration provided by user.

ERP5ProjectUnitTestDistributor allows to define maximum process timeout
of testnodes attached to it.

ERP5Type/tests/testERP5Type.py: Make sure that accessors are protected correctly when permission was specified in the property sheet.

erp5_ui_test: add do nothing reports to Foos
erp5_web_renderjs_ui_test: add export button ui tests

To make basic support for search engines ``description`` and ``keywords``

/reviewed-on nexedi/erp5!253

Make the text clickable.
Do not show text in grey.

your_dummy -> Your Dummy

Since a process might exit by himself at any time, handle exceptions when
we try kill processes

Spotted by chance. Seems unlikely to be hit, but that would be a stupid
arbitrary limitation nevertheless.