Now we rely on implementer decorator

   Base_addSlapOSSupportRequest always created a ticket so no reason to invoke Project_createTicketWithCausality anyway.

Floating point arithmetics often lead to unsignificant differences between
expected and computed values (this is the typical example of `0.1 + 0.2 !=
0.3`). Because of this, some tests using `assertEqual` to compare two floats
were failing. The Python method
[`assertAlmostEqual`](https://docs.python.org/2.7/library/unittest.html#unittest
.TestCase.assertAlmostEqual) can prevent these issues by comparing values up to
the seventh decimal place. To find all occurences, two RegExp were ran on all
files of the `tests/` folder: `assertEquals?(\\(.+, [0-9]+\\.[0-9]+\\))` and
`assertEquals?(\\([0-9]+\\.[0-9]+)`.

/cc @xavier_thompson @tomo
/reviewed-by @jerome
/reviewed-on !719

The old `SafeConfigParser` class has been deprecated since Python 3.2, and was
fully dropped in Python 3.11. See issue
[#45173](https://bugs.python.org/issue45173) on Python's bugtracker.

/cc @xavier_thompson who may ping anyone else if needed

slapos_accounting: calculating the outstanding deposit amount need to also check the balance which include the VAT

Test: ensure a second service can be ordered

so that we can click on the link

   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