A Software Product is a variated resource with 2 axes:
- Software Product Release Variation (optional variation),
  to not force updating Order/Delivery every time one Instance is upgraded
- Software Product Type Variation
It is linked to a Project (virtual master).

Redesign the Upgrade Decision logic.
It is now a Ticket, generated by the Allocation Supply configuration:
- upgrade is different for every Project
- upgrade can be triggered on a specific Node, or for a specific user

Upgrade Decision is created automatically only if there is a single possible release allocable
for a Software Product.
Otherwise, it must be created manually.

The Upgrade Decision must be approved by the Project manager,
who is responsible for the Allocation Supply configuration.

Also in this commit:
* drop template usage
* trigger alarm with interaction workflow

A project reference is required to create a compute node.

Add compatibility with the user request
Console client does not send a project reference.
Try to guess it for simple cases

Drop the allocation scope open/subscription/public logic.

Instead, use Project as Virtual Master, and force
all slapos_cloud object to be linked to one Project:
* every Compute Node is linked to a Project
* any Project's Instance can be allocated on a Project's Compute Node

Allocation is managed by configuring an Allocation Supply document,
which defined on which Compute Node a Software Product can be allocated.

User are not allowed anymore to change the release/type/shared state of their Instance Tree.

Managing Compute Node is done on the virtual master level, and so,
there is no need to define any Compute Node administrator.

A Software Product is a variated resource with 2 axes: software release url and softare type.

Slave Instance are now allocated on Instance Node, which is created
from the Software Instance which will control the configuration.
Slave Instance allocation is also controlled by an Allocation Supply,
which allow separating the Software Instance and Slave Instances versions.

There could be any number of virtual master in the system.
Every virtual master defines its own Software Products.
Because of this, it is not possible to change a document's virtual master
after its creation.

Instance request can be propagated on another virtual master, by
allocating them on a Remote Node document, which will generate
a new Instance Tree request on another virtual master.

Also in this commit:
* trigger alarms as soon as possible with interaction workflow
  which allows to reduce some alarms frequency
* drop never used Organisation logic
* drop person.requestSite
* drop audit_validation_workflow
* drop ComputePartition_getCustomAllocationParameterDict
  This is a hack incompatible with virtual master standalone logic.
* drop cloud contract
* do not sort security base category when generating local roles
  Otherwise, it is not possible to ensure source_section/function and destination/function generate the same local role
* stop using hardcoded currency/organisation/trade condition/business process
* drop templates usages
* add One Time Virtual Master Access Token portal type
  Needed for compatibility with the compute node deploy script

* automated ledger
* drop allocation_scope/open/* categories
  All compute nodes are public now
* add use/trade/deposit category
* add trade condition type categories.
  This will be used to automatically select a Trade Condition in slapos_accounting
* add invoicing taxable vat categories

* drop default_or_child_aggregate_reference
* drop default_or_child_aggregate_uid catalog key
* drop follow_up_default_or_child_aggregate_uid
* drop causality_subscription_request_related_uid related key

This make usage of the relationfield nicer.

This reverts commit d127603b.

  This is required due interacton workflow call on _setAlloctionScope.

  We could change the capacity_scope to close (so allocation worklfow order dont matter, but
  it would change the expected behaviour if we drop the interaction workflow, so it is more
  reasonable keep the existing behaviour unchanged.

See merge request nexedi/slapos.core!615

same as nexedi/erp5@2e366054

With the previous approach, the test depend on the order of attributes,
but this order is not stable when hash randomization is enabled and we
don't care about order of attributes in this test.

This is no stable with hash randomization, with PYTHONHASHSEED=593 this
test failed.

slapos_cloud:testSlapOSCloud fails with PYTHONHASHSEED=385

this is done by upgrader in production, so it's consistent to do it
before test

sorted and with the usual workaround for trailing space bug

See merge request nexedi/slapos.core!613

See merge request nexedi/slapos.core!614

  This is quite specific to project based instances, so no need to add into every instance

  Test some particular cases or features that MUST not be used, to ensure nobody the editor is handling it properly.

See merge request nexedi/slapos.core!609

See merge request nexedi/slapos.core!612

  Latest version had significant changes, so pin the version for now

See merge request nexedi/slapos.core!611

Since ERP5 commit 6546e47f51 (erp5_software_pdm: a Software Product is
a Service, 2022-09-07), the message changed

  This cause editor do not render the form.

   It is better use the parameter_xml directly since, since there are no need for the editor
   handle hashed version of the parameters.

It's been a while the server is ready.

See nexedi/erp5@c45c2295