* drop template_software_installation
* drop template_instance_tree
* drop template_member
* test: fixup
* test: drop updateLocalRolesOnSecurityGroups calls
* test: drop usage of organisation_module.slapos
* stop using dropped related keys
* test: use dedicated scripts to create Ticket/Event
* test: Event_getRSSTextContent does not exist
* drop immediateReindexObject
* fix context_related parameter usage

* source_administration is not used anymore on Compute Node
* add virtual master contraint to tickets and events portal types
* propagate project from Regularisation Request to event
* delivery/movement must use source_project instead of follow_up
* set source_project on event
* stop setting person as source_project
* copy project from ticket to the new event
* utf-8 encoding issue
* XXX disable regularisation request alarm
* Regularisation Request Module acquires local roles
  See other modules
* drop upgrade_scope
  Upgrade is managed by Allocation Supply.
* drip upgrade_scope usage
* drop Upgrade Decision Line usage
* lint test
* fix slapos_crm_check_software_installation_state alarm test
* fixup slapos_crm_check_compute_node_state tests
* fixup slapos_crm_check_instance_in_error test
* fixup slapos_crm_update_support_request_state tests
* fixup slapos_crm_send_pending_ticket_reminder test
* fixup slapos_crm_trigger_stop_reminder_escalation tests
* fixup slapos_crm_trigger_stop_acknowledgment_escalation test
* fixup slapos_crm_trigger_delete_reminder_escalation test
* fix slapos_crm_trigger_acknowledgment_escalation test
* fix slapos_crm_stop_instance_tree test
* fix slapos_crm_invalidate_suspended_regularisation_request test
* fix slapos_crm_delete_instance_tree test
* fix slapos_crm_create_regularisation_request test
* drop slapos_crm_check_update_allocation_scope tests
* do not require source_project on crm
* fixup rebase: drop Instance Tree Module | slapos_resilience_usage_report
* drop preferred_support_request_template_property
* drop slapos_crm_support_request_template
* fixup slapos_crm_create_regularisation_request tests
* reactivate slapos_crm_create_regularisation_request
* test slapos_crm_invalidate_suspended_regularisation_request is ok
* test slapos_crm_check_software_installation_state
* test slapos_crm_check_instance_in_error
* test slapos_crm_update_support_request_state
* desactivate Person_getSubscriptionRequestFirstUnpaidInvoiceList
* drop Person_getSubscriptionRequestFirstUnpaidInvoiceList
* do not count all Support Requests
  limit parameter with count is meaningless, as count return 1 result
* update Base_getSupportRequestInProgress usage
* XXX disable ticket.notify and ticket.requestEvent
* wip script to create Support Request and Event
* search a matching Trade Condition to generate a Support Request
* update ComputeNode_checkState to use new scripts
* test ComputeNode_checkSoftwareInstallationState
* deliver outgoing events
* test InstanceTree_checkSoftwareInstanceState
* Project_createSupportRequestWithCausality already checks if Support Request exists
* no need to check twice the object portal type
* test SupportRequest_updateMonitoringState
* activate one more alarm
* revert  Send Mail on pending tickets
  nexedi/slapos.core!417
  Virtual Master's manager are responsible to handle the tickets through their worklist.
  Not user.
  Virtual Master's manager can send email from the Ticket to directly ping a user.
* drop ticket_slap_interface_workflow
* test ComputeNode_hasContactedRecently
  Do not check if there is a packing list. It is unrelated to the contact.
* Base_getOpenRelatedTicketList was dropped
* ComputeNode_checkAndUpdateAllocationScope was dropped
* test: simplify
* set comment in the event workflow history
* send Mail Message
* unify event creation
  Reuse Ticket_createProjectEvent
* do not pass a empty list of node_uid
* no need to manually handle the notification message
* create the Regularisation Request from a Trade Condition instead of a template
* use notification message title instead of the ticket title
* use Entity_hasOutstandingAmount
  Entity_getOutstandingAmount is meaningless in case of multiple source_section and multiple currencies.
  Entity_hasOutstandingAmount will only report True or False.
* test RegularisationRequest_invalidateIfPersonBalanceIsOk
* test RegularisationRequest_checkToTriggerNextEscalationStep
* test RegularisationRequest_triggerStopReminderEscalation
* test RegularisationRequest_triggerStopAcknowledgmentEscalation
* test RegularisationRequest_triggerDeleteReminderEscalation
* test RegularisationRequest_stopInstanceTreeList
* test RegularisationRequest_deleteInstanceTreeList
* fixup RegularisationRequest_checkToSendUniqEvent tests
* fixup RegularisationRequest_checkToTriggerNextEscalationStep tests
* fixup InstanceTree_stopFromRegularisationRequest tests
* fixup InstanceTree_deleteFromRegularisationRequest tests
* drop slapos_crm_regularisation_request_template
* drop slapos_crm_web_message_template
* drop preferred_web_message_template_property
* drop slapos_ticket_trade_condition
* drop update_destination_for_slapos
* drop allocation_tester
* drop template_software_installation
* drop template_instance_tree
* drop template_member
* test: fixup person title
* test: fixup: ensure tickets can be created
* test: fixup creation of instance tree
* test: fixup instance tree creation
* test: ComputeNode_getTicketRelatedList was dropped
* test: rss feed will be used by virtual manager production
* test: ticket.approveRegistration was dropped
* ExactMatch
* drop preferred_cloud_contract_enabled_property
* only submit the newlu created Support Request
  end user can not validate their submitted ticket
* drop jump_related_slapos_item
* drop outdated SlapOSSupportRequestConstraint
* submit created event
  This allow to separate new ticket from the one currently handled
* constraint was dropped
* test: create test ticket in submitted state
* support request are created in submitted state
* drop open/personal allocation_scope
* only check automated Outstanding Invoices
* invalidate Regularisation Request as soon as payment is done
* create the regularisation request as soon as possible
* use _baseSetGroupingReference for interaction
* test: disable interaction
* test: use PinnedDateTime context
* delete instance, compute node, project if regularisation request reach the end
* test: add crm scenario showing services are destroyed
* trigger Project invalidation as soon as Nodes and Instances are invalidated
* trigger not paid item deletion as fast as possible
* test: reduce number of alarm triggered
* do not stop but delete directly
  Services were already in degraded mode due to allocation/propagation being forbidden
* test: only payable services are destroyed by the subscription request

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

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

* add new business application categories
* export edger category
* automated ledger is not only for accounting
* drop allocation_scope/open categories
  All compute nodes are public now
* add use/trade/deposit category
* do not use the same title for 2 categories
* 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 unused 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.