slapos_erp5: production users can create invitation token

slapos_erp5: do not allow creating Contract Invitation Token anymore

slapos_erp5: invitation token roles

slapos_erp5: trigger invitation token local role generation

slapos_erp5: is an Invitation Token a ticket?

slapos_erp5: test invitation token roles

slapos_erp5: roles for Assignment Request

Reopen the support request when a new event is created

See: https://lab.nexedi.com/nexedi/slapos.core/-/blob/5e430ca2f21110900226c351bc5f5867e1ed3afe/slapos/slap/hateoas.py#L462

See merge request nexedi/slapos.core!677

   Shadow user have no access to Allocation Supply exclusive to the user, so access the variation before change into shadow user.

   Include a constraint to ensure group is set when function/accounting/{agent,manager} is used on
   assignments.

   This custom approach is used on Panel View and it is only working properly for Panel View since the gadget that will be redirected into is the slapos_panel_view.

   When use normal renderjs_runner it may cause confusion, so keep the URLs just pointing to normal locations.

   This helps administrator to identify which project the ticket is related too.

    This ticket list is broken and it is duplicated with Panel View anyway.

   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.