[erp5_web_monitoring] Fix concurence problem on destroy OPML while sync is running or start just after

If Sync start in background and destroy OPML is launched, some data can be removed while sync is writing. So we prevent sync to run if destroy OPML is running and also, we refuse to destroy OPML if sync is running.

If the search result is only one item, redirect to the item view page, else redirect to the list of that items and let user choose the good one.

Monitor Jio storage has been updated to fix monitoring global Json files and set correct portal_type to it. The fix allow to keep backward compatibility with old/non updated monitoring backend instance.

This reverts commit ec926ea5.

This commit is still experimental, it was not supposed to be part of
this push.

This breaks matrix index consistency.
Also, call isBasePricePerSlice rather than introspecting wrapped method
arguments - the only wrapped method is _setBasePricePerSlice anyway !
Also, trigger SupplyCell_updateSliceBasePrice as it depends on
isBasePricePerSlice value on this line, and it just changed, and that
workflow does not trigger on line changes (which is a bug).
Also, get rid of a trivial local variable.

Rather than deleting them to just immediately create new ones with the
same ids but different uids.
Also, modernise code and follow naming conventions and coding style.

"self._m" may trigger "implicit self argument" magic. Follow how the
rest of this class accesses this property.

This was comparing the two selected documents in random order, which
caused some test failures sometimes but also was not user friendly. Now
the oldest should always be on the left and newest on the right.

Also drop Base_getObjectPathFromSelection which became not used.

also remove these links that are no longer valid

The error was found with MariaDB 10.4, which returns results (of a
request without ORDER BY) in a different order than previous versions.

We do not chunk at this level.

Neither our code nor requests encodes the body this way
and waitress (WSGI) considers the request is corrupted.

It worked so far because Medusa ignores this header field.

Set int_index at Test Result creation time as it is really needed for showing graph, test order execution in case of Scalability Tests and use int_index in scripts.

Test Result Line do not have properly set int_index, instead title have been used in past. Until properly set (int_index) use current way for sorting. This is especially important for Scalability Tests's graphics.

This MR introduces a second way of calculating the base price of a resource using "Base Price Quantity Step".

Currently, for a resource, we could define on a Supply Line "Quantity Steps",  and set a price for each of these steps. Then, depending on the quantity of the resource, the price of the unique matching step would apply.

For exemple : 

| Quantity Step Range | Price for the step|
|------------|---------|
| 0 -> 10 | 10€ |
| 11 -> 20 | 9€ |
| 21 -> inf | 8€ |

With the current method, for an Order of 15 products, the 2 range "11 -> 20" would apply, the unit price for the products would be 9€, and the total price would be 15*9 = 135€.

The new method of calculating would apply the _Price for the step_ __to, and only to, all items of this step__. Which means, for an order of 15 products, the 10 first products would have a unit price of 10€, and the 5 next products would have a unit price of 9€, which makes in the end a total price of 145€, and a base price of 9.66€.

/reviewed-on nexedi/erp5!896

and add necessary values for calculating price per slice

To be sure that Cells are updated correctly when the pricing method is chosen