This ensure that timestamp is updated, and enforces that cache is updated

  Only launch caucase when needed.  Not all tests need
  caucase, this saves a bit the overhead to run it

See merge request !620

  This test seems never ever implemented since the begin of the project

See merge request !617

   This implements checkValidity properly.

   This bt5 contains all code related to the parameter editor, include the testing dialogs and samples.

   The goal is evolved the implementation and keep code specific separated from the rest of the implementation (so if UI can change and we keep a "generic" implementation.

   Test form was included on Software Product Module due security reasons (so be allowed to be used as normal user).

   On slapos_panel: Reimplement parameter test on slapos_parameter_editor
   On slapos_panel: Move samples to slapos_parameter_editor bt5
   On slapos_cloud: Move code related to parameter editor to slapos_parameter_editor bt5
   On slapos_panel: Drop old test parameter implementation

May allow oauth support in futur

Also in this commit:
* add a test step to trigger all alarms
* update the expected bt5 list

Migrate the previous slapos master logic to virtual master:
Create needed Project, Software Product, Remote/Instance Node,
Subscription Request, Allocation Supply.

Also in this commit: update tests
* use backup cloudooo
  slapos@a729a677
* many dependencies have been dropped
* change module id generator
* portal_callables is not handle by the configurator
  See erp5@a55b0f78

There are 4 types of assigment family:
* The accounting team has assignment like: accounting/manager or accounting/agent
  They can see all invoices, but can not modify the automated ledger
* The sale team has assignment like: sale/manager or sale/agent
* A virtual master customer has an assignment like:
    function/customer
    destination_project/THE_PREFERED_DEFAULT_PROJECT
  He can request instance trees.
  He can see all the nodes on the virtual master.
* The virtual master manager has assignment like:
    function/production/manager
    destination_project/THE_PROJECT
    or
    function/production/agent
    destination_project/THE_PROJECT
  He is responsible to create the compute node and ensure the quality
  of the service provided on it (so, he manages the related crm).

Worklist must be usable, to quickly allow any user to know what is
expected from him in the system.

Also in this commit:
* change the module id generator to _generatePerDayNodeNumberId
  to reduce conflicts on object creation
* change bt5 dependencies to use the new panel UI

Keep only code which was not yet migrated.
This bt5 is not supposed to be installed anymore.

Simplify maintainance of the panel by putting back the business logic
into ERP5 actions.

This allows to:
* view panel actions in ERP5JS too
* use formulator to define what a user see
* not write JS code for every page

We loose the offline functionality, but this was never finished.

Modules switched to per day/node ID generator.

Also in this commit:
* drop not needed trade conditions

Modules switched to per day/node ID generator.

Also in this commit:
* drop templates
* drop not needed trade conditions

Unify Ticket and Event creation, to ensure consistency on the different categories.
Use causality category instead of aggregate, to link the Ticket to the context document (instance, node, ...).
Aggregate must be used to define the item of the movement resource.

Monitoring: the tickets are managed by the virtual master admin,
who is responsible to provide a good service quality.
Admin will use their worklist to see the ongoing tickets.

Regularisation Request: this ticket is handle by the accounting team.
Unpaid invoice can be related to any kind of service (instance, node), which
have only 2 states from the ticket point of view: running or destroyed.
Only check the automated ledger, do not be impacted by other kind of invoices.

Prevent allocation if a customer has an ongoing Regularisation Request.

TODO: handle case of unpaid invoices for professional customers

Also in this commit:
* drop templates
* use interaction workflow to trigger alarms

A Subscription Request is a ticket, which should be used to generate an Open Sale Order for a service.
When the Open Order is created, the ticket is closed, and not used anymore.

Drop the Subscription Condition object.
Using Sale Trade Condition is enough to define all the Open Order profiles.
Using Sale Supply is enough to define the prices.

As services can be created from SlapOS API, the Subscription Request
can be created after the service already exists.
Block allocation until the Open Sale Order has not been yet created.
User will be able to fill the services details, without it being used in the system.

Open Sale Order must be created, even if the service is free, to allow
using the inventory API on the services (using Packing List).

In order to reduce the number of invoice for the customer, ensure the
invoice date is stable for a customer, and provide discount to not invoice
unused period.
Do not use the same date for every users, to reduce load on the system
for that day.

To accept a payable service Subscription Request, the customer must
provide a deposit, which may be used to pay a not paid monthly invoice.

Also in this commit:
* drop not needed templates
* use interaction workflow to trigger alarms
* drop ecommerce dependency

Instead of having a giant versionned Open Sale Order, containing all user
subscriptions, create one Open Sale Order per subscription.
The Open Order state can now be used to mark the subscription status.

This reduce the simulation tree size, as a such tree will not be
updated anymore when a subscription ends.

The Open Order stop date is set when closing the Open Order.

Create a new 'automated' ledger category, to explicitely mark the
deliveries managed by the alarms / scripts.
Drop the explicit reference of a specific business process / trade condition,
and allow any Trade Condition to be used, based on its predicate/trade_condition_type configuration.

Ensure the items are propagated in the simulation movements and delivery lines.

Aggregate Sale Invoices, based on their Trade Condition and profile values.
A user will have multiple invoices if he is using multiple virtual master's services.

Implement a VAT calculation for France only for now.
Delivery Line with a taxable business_contribution must trigger the
tax calculation script (which depends on many factors like type of sold items, customer address, ...)
and explicitely mark on the line the VAT rate.
Customer address can be modified in futur, without impacting the delivery
vat calculation.

Also in this commit:
* drop template usages
* use interaction workflow to trigger alarms
* do not generate invoice with a 0 total price
* drop hardcoded reference of hardcoded currencies
* add contraints on the simulation logic, to prevent generating wrong movements
* configure Sale Supply to allow more complex price definitions
* allow using any kind of resource on the deliveries
* disable consumption delivery generation (until better specified)
* stop forcing/hardcoding payment mode in advance
* support for variated resources
* allow to manually pay multiple invoices with a single payment
* drop the cloud contract tricks
* destroy items as soon as the Open Order is closed
* add a discount service to reduce the invoice price if wanted
* add a deposit service to support invoice prepayment