Until now, standalone was running slapos node software/instance with --all flag
which force installing software or processing software, unlike "normal" slapos
node which no longer install on software once they are completed and only process
instances when they are requested with different parameters or when they have
failing promises.

We stop using the --all flag, to behave like a normal slapos node.

This reveal missing promises in some softwares, after this change, waitForInstance
can return faster. This reveal test failures with some softwares where the
instanciation step request other instances, but without having a promise to wait
for their requests to have been sucessfully processed; in this case waitForInstance
return too early.

We keep an "install_all" API to force reinstalling software, this can be useful
for scenarios like erp5testnode, or software release development.

Installing from a git checkout is a bad practice for production, but it's a
common thing during development. One problem I often face is that I have a
software release installed from a given revision and I want to make a small
change to the software, but not recompile everything. To achieve this, I need
to use the exact same git revision that was installed before, but most of the
time, I don't remember what revision I have been using last time I installed.

This change is about adding a buildout comment in the generated buildout.cfg
made to install the profile, with the revision that was used for installing, so
that we can re-install the same software again.

See merge request nexedi/slapos.core!302

See merge request nexedi/slapos.core!301

See https://lab.nexedi.com/nexedi/erp5/blob/1b31fcbd12ede57079851aa198aa8d9e9f70e073/bt5/erp5_web_renderjs_ui/PathTemplateItem/web_page_module/rjs_gadget_erp5_datetimefield_js.js#L281

Provider of the Software Installation is Assignee.
See nexedi/slapos.core@07c9102c

It was probably a typo in nexedi/slapos.core@b0b435ce

This reverts commit 2270e851.

Install erp5_full_text_mroonga_catalog as a direct dependency.
This simplify the installation process.

Since during maintenance of Hosting Subscription it's possible to end up with
many root Software Instances (of which many might be destroy_requested) it's
needed to support such situation while creating upgrade decision and finding
upgradeable Software Release.

   Contributed by Romain

- more reliable crontab parsing
- execute command the same way as dcron
- fix poor escaping when execute command

  Usage of raise it don't lead to inconsistency
  Since we can merge aggregated Packing Lists, now we consider the sum() rather the invidual comparation.

  Contributed by Romain.

    Invoice Number is added to make easier to user track which invoice is which.

See merge request nexedi/slapos.core!294

   Include wider coverage on the security tests related to the "Share" feature,
   implemented via Tracking API.

See merge request !288

For technical reasons the ? for Software Release allows simple hacky multiple
software releases to be created, which share exactly the same profile code,
and so JSON Schemas. So for such, use original Software Release JSON Schemas.

This commit introduces the `local_software_release_root` parameter.
This parameter is then forwarded as the SR root path for slapproxy.
By default the value is `/`, the same as the default in slapproxy.

The 'local_software_release_root' parameter can be set in slapos.cfg:
    [slapproxy]
    local_software_release_root = <path>
or via the command line using:
    slapos proxy start --local-software-release-root <path>

When slapproxy starts, it updates all local URLs that are subpaths of
the previous root path to be subpaths of the new root path instead:
    <previous-root-path>/<subpath>   =>   <new-root-path>/<subpath>

The default root path is '/'. This means that by default slapproxy
behaves the same as before.