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

  DeprecationWarning: <Workflow at instance_slap_interface_workflow>: Script calling Instance_checkConsistency instead of script_Instance_checkConsistency

   Provide all common options as a method, so it is easy to understand security.

moved from erp5 SR test suite

See merge request !705

adjusted to use findFreeTCPPortRange and fix typing / formatting errors

  Ensure to convert the text values to a safer output that will be compatible with XML 1.0.
  See: https://www.w3.org/TR/REC-xml/#NT-Char

   Try to guarantee that data is consistent and wont fail later on
   while been converted to XML with special attention to non-XML
   compatibles characters, like backspace.

   Include constraint to ensure title is XML compatible on Software
   Instance, Instance Tree and Slave Instance. (Not required for Compute
   Node as far as I checked).

   Copy text_content (parameter), sla_xml constraints from
   Software Instance to Instance Tree and Slave Instance.

   Copy connection_xml constraint from Software to Slave Instance for
   consistency.

   Add more tests to ensure that an Instance cannot be created if data
   is invalid, or not XML compatible.

   Add utility scripts to validate XML and XML Marshaller compatibility

This is a fixup of 3194cc75.

slapos_crm/panel: rename Project_createSupportRequestWithCausality to Project_createTicketWithCausality

Prepare support for new ticket portal types.

User is not visible in the panel.

It should reduce number of open order expand calls.

requestStart seems to be called on every instance every day.
There is no need to call the alarm if nothing changed on the instance

slapos_cloud: allow recreating a Compute Node even if there is an invalidated node with the same title

   Insert suffix on RSS Entry title, to better indicate what is the notification is about.

   MONITORING was widely used already, so it drops the need for custom entries.

   not monitoring.

   It is broken, unused, and it is saves no time in general. It is better rely directly on sync to get all information on monitoring, or improve Support Request UI itself.

   This import Raw/Custom OPML feature is not support anymore on Monitoring app. The sync occur directly from jIO API, so no reason to keep it.

   The code is also broken and untested in general.

   Overtime, the compute node can fail differently before the administrator take action, create multiple tickets for the
   same compute node don't help.

   Whenever you have a ticket for a computer or instance, it is irrelevant to create a second since the unsolved first one
   is most likely the source of the second one.

   Fewer tickets increase efficiency, and encourage no ticket pending policy and to resolve the problems.

  Keep testSlapOSCRMAlarm for regularisation request related alarms
  Create testSlapOSCRMMonitoringAlarm for tests related to Monitoring ticket creations and so on.

    Merge into Project_checkMonitoring for launch per-project basis.

   Refactor the implementation of the alarms:

      - Search from Project rather them query compute nodes, directly
          respecting if the project can create tickets

      - Split ticket creation from messaging introducing
          *_getReportedErrorDict to calculate the error messages
	  (so we can re-use them)

      - Merge 2 alarms (for check compute node and check compute software
          installations) info a single one, so we launch at least half
	  the amount of activities for compute nodes.

      - Drop the specific alarm and to issue a ticket if the user has an
	instance on a 'close/forever' compute node

      - Reimplement SupportRequest_recheckMonitoring

   Merge SoftwareInstallation_getReportedErrorDict into ComputeNode_getReportedErrorDict:

     We only check for problems from Compute Node perspective, so we should
     report only one ticket per time.

     SupportRequest_recheckMonitoring can guarantee that the compute node
     don't have other problems while closing the ticket. So, this reduces
     the scope of checks, for example, if the computer isn't connecting,
     there is no point in check all software installations inside. Another
     example is, if multiple software releases are failing we dont need to
     report each one, since the administrator is informed and create
     multiple tickets for the same compute node will only spam the
     administrator.