On xml serialisation we support a more restrict scope them the whole json schemas and on json-in-xml, despite the fact we could support all, not everything is suitable for form generation.

   The both "meta schemas" are a variation of the draft exclusively for UI rendering purpose.

   Keep this code would only make things confusing, since this code is mostly an archive

   If they exist.

Since the way of renaming the software_release_url proven to avoid having
unexpected results AND it is required in many cases to directly destroy an
instance, allow direct destruction of such instances.

See merge request !374

   This allow user edit the text area to fix the parameters and try to reload the form.

   This feature isn't used or required anymore.

   Whenever a user changes the Raw XML them return to the form, the  changes on XML are loaded into the form. This allow the user reuse a known xml form as template.

   Whenever a parameter is incompatible with the serialization (by the use or not of "_" special parameter) the form should display a textarea as a failover.

   Whenever the parameter editor fail to render the form, the selection box (with the software type) shouldn't be hidden, so the user can still change to a proper Software type with a proper serialization (as long it allow you to are requesting an instance and not editing).

See merge request nexedi/slapos.core!373

The promise runner launched in a subprocess with the instance's python
redirects stderr to stdout in order to reserve stderr for propagating
error messages.

However `preexec_fn` is used to run `dropPrivileges` inside the child
process, so when `dropPrivileges` calls `logger.debug`, the logger
writes to stderr before the redirection is set up.

To fix this, the `preexec_fn` function is modified to apply the same
redirection first and revert it at the end. Reverting it avoids the
need to communicate the new file descriptor for the original stderr
stream to runpromise.py.

The vulnerability that this test was checking was removed from the
database, let's use another one that looks more likely to be removed.

See merge request nexedi/slapos.core!368

this option was only used in generate-signature-key of
slapos.libnetworkcache but it has been removed in
slapos.libnetworkcache@765d4737

   This is same API already present on compute node, the core diference here is that the Software Instance oddly store the value.

  This clean up code, and the instance should be be responsable for this conversion
  as it is all instance related parameters anyway.

   Help evaluate if the data is actually the last already

   This prevent us rely on SlapTool implementation to search the Software Installation for a given URL

  Create specific API for status suffixes, since this is a widely used by monitoring system

  Move to workflow tranistion the duty of reset/set last data, so it work regardless of slaptool.