Now we rely on implementer decorator

  it cause confusion on grep and search, if we need access its code,
  we may rely on https://lab.nexedi.com/nexedi/slapos.core/-/tree/master/master/bt5/slapos_jio

  This helps to emulate payments, so we can test outcome before/after payment to wechat

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

   If a software instance with 1 or more slave instances allocated on it is destroyed the instances aren't reallocated, so let's create a ticket to high light the problem.

  Probably a copy and paster or typo.

   Destination is never set... Destination Section is a proper value for the condition.

   Whenever the Upgrade Decision arrives at final state (Close, Reject, Cancel) all stopped events are delivered.

   The upgrade decision portal type should be return whenever getPortalTicketTypeList() is called.

   This aims to fix Worklists for Events when they follow up to an Upgrade Decision.

   On final state, we just deliver all stopped events related to Subscription Requests.

   While the Subscription is submitted, the events will be kept stopped,
   so the manager (accountant/sale) can have it on their worklists.

   Add tests for new alarm

   Invoke alarm to deliver related events, whenever the Susbscription
   Request is invalidated (end of life).

   Rename *[sS]toppedEventToDeliver to *[sS]toppedEventFromSupportRequestToDeliver to reflect proper usage
   Add *[sS]toppedFromEventRegularisationRequestToDeliver to handle delivering of Events from Regularisation Request via new alarm
   Update and add tests accordingly.
   Narrow the slapos_crm_interaction_workflow to only trigger alarm if the follow up portal type is relevant, to not over trigger the alarm on excessive amount of occasions.

   On final state, there is nothing that could be done, and send a message won't be seen on worklists anyway.

    Only [Accounting|Sale] Manager can validate the ticket (interrupting the process)
    [Accounting|Sale] [Agent|Manager] can suspend the ticket (continuing the process)

   It differs from Support Request (no recheck no project..)

   The Regularisation Request columns differ from Support Request now, since it has no re-check or project.

   Since Regularisation Request is created by lack of payment, usually the accountant is the one that can reply about ways of payments, and the one that can include manual payment (ie.: Wired transfer).

   Future possible use cases (Regularisation Request for Org?) would require accountant help to handle payments.

   Update related tests.

   Accounting Agent is assignee (like sales agent)
   Accounting Manager is assignor (Like sales manager)

   Only Assignor can re-open (pause) the process to destroy unpaid instances.

slapos_crm: create monitoring Support Request for Slave Instances in error, and instances on a Remote Node

Detect url/type changes which are not compatible with the remote project.

See merge request !696

This will support buildout extension to download from gitlab API with
authentication.

The code has already been refactored a bit to be able to pass a
download instance to SoftwareReleaseSchema, for now to instanciate only
one Download but in the future this might be extended to pass some
configuration to the Download instance.

The performance was much worse.

Workflow state was not the correct one.

See 76edda30

This partially reverts commit 14c39681.

There is no need for custom the actions, as on slapos_panel fast input is
used instead.

Keep for now the older state name for ensure consistency with the current
usage.

   This was replaced on the panel so, no need to have it on workflow action. This may reduce the delta on the workflow itself.

   For sure, we won't calculate worklist from this form

    This workflow isn't used any more since the re-implementation.

   This prevents produce inconsistent objects whenever system evolve.