This information is duplicated with Panel View anyway, no reason to keep it

   Whenever the serialization is JSON-in-xml the parameters are uploaded into {'_' : '{}') format.

    Add mixin to Remote Node and Instance Node, so they can respond to getAccessStatus calls.

    Despite we don't set data on it (same for Slave Instance), it is important to respond this API to display
    Property the Status Gadgets on the API.

    Later on we can setAccessStatus based on Software Instance (for Instance Node) or Compute Node
    based on some indirect criteria, but this not covered by this commit.

This part was not following the new design.
Use the new Type variation document to define how much a instance consumes the compute node capacity.

Manager were using it on previous oss web site

It will reduce the transaction time, and so, reduce conflict cost

Ensure instance is indexed before propagating to the remote node

Do not propagate any url/type change (created by destroy and rename action).

slapos_crm: do not create ticket if we do not have any information for the software installation status

This was the behaviour before the virtual master migration.
Restore it, to not create too many tickets for now.

Paramers are not propagated from Instance Tree to Software Instance, as the manager does not have access to the Open Sale Order AND the customer person.

UID is not a list

The `_verbose` attribute of `SlapOSInstanceTestCase` was unused and it
is now removed.
As the `makeModuleSetUpAndTestCaseClass` needed to be edited to remove
`_verbose` from the class type instantiation, that function has been
formatted, documented and typed.

See merge request nexedi/slapos.core!664

Class attributes of `SlapOSInstanceTestCase` have been typed and
documented.

See merge request nexedi/slapos.core!664

This adds the `request_instance` class variable to
`SlapOSInstanceTestCase`.
If this variable is false, no instance will be requested.

See merge request nexedi/slapos.core!664

 - warn with all json validation errors, not just the first one
 - make validation error message easier to understand by not including
   so many useless details
 - do not let jsonschema fetch schema references by providing our own
   fetch implementation

Do not access destination section value when updating instance tree,
as manager can't access customer info

slapos_accounting: a single payment transaction can be used to pay multiple invoices with different destinations

Define the source_project on the newly created Sale Trade Condition