Previous code matched way too many files as belonging to the current
partition and wrongly removed them as obsolete: e.g. when processing
slappart1, all the configuration files belonging to slappart10 would
systematically be deleted, as if they belonged to slappart1 and were
now out-of-date. Same for all partitions starting with 'slappart1',
such as slappart11, slappart12, etc.

This resulted in all services in slappart1X being stopped and started
repeatedly and very often: stopped during processing of slappart1 and
started during processing of slappart1X, with potentially several
minutes of downtime, and a high percentage of downtime.

This is a fixup of db98a521.

This method is important we want to test it

See merge request nexedi/slapos.core!577

  Since we are changing erp5_site_global_id, update cache is mantatory be called often

See merge request nexedi/slapos.core!576

This could cause slapos request to hang forever while fetching the
json schema of an SR, and in particular it could cause buildout to
hang forever in instance processing when requesting a sub-instance.

See merge request nexedi/slapos.core!575

See nexedi/slapos.package!187

   This constraint has no impact and you change your environment (ie.: use another memcache server) fix consistency will just break the system.

   This constaint also contains hardcoded values (which is already the setupped) so it dont make much sense keep this constraint around doing nothing.

   The user should be able to eventually change the cloudooo configuration after the setup it w/o change zope.conf.

   Just give some valid default if nothing is set, there is no reason to make things more complex them this, since the cloudooo_url is already setup on site creation.

  Rely on standard ERP5 implementation is enough

  Some values are set on testing environment, so no need to rely on IsLiveTest

See merge request !573

Also remove support for very old OSes.

See merge request nexedi/slapos.core!572

When upgrading from a version of slapos.core that does not support
processing instances without a connection to master to one that does,
the following edgecase could occur:

1. some partition is stopped and processed with old version
2. slapos.core is upgraded
3. connection to master is lost
4. offline processing wrongly starts the services of stopped partition

This was because the new version removes the supervisord file for a
partition when the partition is stopped (in online mode) so that the
offline mode can just start all the existing supervisord files. But
since the partitions was never processed in online mode with the new
version, this file was never removed.

To fix this, we use the (now no longer used ) .requested_state file
of the previous version to determine the state of the partition in
offline mode, then we remove both the .requested_state file and the
supervisord file, fixing the discrepancy.

Connection loss may result in `slap.exception.ConnectionError` being
raised during instance processing in addition to `RequestException`.

See merge request nexedi/slapos.core!571

   Reuse status gadget so it has the same information as its displayed to the user.

   This is a clean up, there seems to be legacy calls from before the form was refactor. This speeds up form rendering by a lot.

  It is easier to write better tales expressions

See merge request nexedi/slapos.core!569

  On normal UI, this allow use this UI for edit parameters also.

  it only confuses users

   Clean up unrequired code
   Use domsugar rather them createElement for simplification

   This also ensure all events are loaded also

   The form is submitted before the valued input is taken into account due the speed of the robot.