This new report class is responsable for generate a file (serealising it per pertition),
  instead rely on concurrent calls to the sqlite.

  This is just to clean the methods a bit

  Extend monitor to grab this information, this allow us use slapos node collect more efficiently, and
  prevent others softwares to access directly the database.

/reviewed-on !147

When having more than one read_only_shared_part_list, the template was
first rendered with indentation and then dedented, but since dedent only
remove the common indentation, we ended up with slapos.cfg like this:

```
$ cat /data/slappart11_testnode/cqg/inst/test0-9/tmp/etc/slapos.cfg

            [slapos]
            software_root = /data/slappart11_testnode/cqg/inst/test0-9/tmp/soft
            instance_root = /data/slappart11_testnode/cqg/inst/test0-9/tmp/inst
            shared_part_list =
              /srv/slapgrid/slappart11/srv/shared
/srv/slapgrid/slappart11/srv/testnode/cqg/shared
              /data/slappart11_testnode/cqg/inst/test0-9/tmp/shared
            master_url = http://10.0.12.198:46312
            computer_id = local
            root_check = False
```

First dedent, then render the template to prevent this issue. Apply this to
other uses of textwrap.dedent for consistency.

/reviewed-on nexedi/slapos.core!140

When the testnode installing `slapos_subscription_request`, it reports:
```
2019-10-08 19:09:59,997 INFO     runTestSuite: Adding erp5_web_renderjs_ui business template ... (imported in 2.513s) done (21.342s)
2019-10-08 19:09:59,997 INFO     runTestSuite: Adding slapos_subscription_request business template ... (imported in 2.692s) Traceback (most recent call last):
.....
2019-10-08 19:10:00,008 INFO     runTestSuite: ValueError: "commerce_validation_workflow" is not a workflow ID
```

I found the `commerce_validation_workflow` is inside `erp5_commerce` bt. So I add `erp5_commerce` as the dependency of `slapos_subscription_request`.

/reviewed-on nexedi/slapos.core!141

This new option for slapos.cfg allow to define a list of paths to use
for shared parts feature of `slapos.recipe.cmmi`.
This will be injected in the buildout profile used to install software,
as `${buildout:shared-part-list}` which is the option `slapos.recipe.cmmi`
use since 0.11.

Note that the option changed in `slapos.recipe.cmmi` because this was
incompatible. In 0.10, the option was named `${buildout:shared-parts}` and
it was supposed to be a single path. `slapos.recipe.cmmi` 0.10 was trying
to create this path. If we continued using this `${buildout:shared-parts}`
option and changed to passe a newline-separated list of paths, then
`slapos.recipe.cmmi` would just create one directory with \n in the name
and will probably fail, which would make all software from 1.0.73 to 1.0.121
not installable on next `slapos.core`, so we used another buildout option
to prevent this problem.

Because generally, profiles using slapos.recipe.cmmi 0.10 were not
"safely" shared, we don't even provide compatibility with old option.

/reviewed-on nexedi/slapos.core!46

This is about replacing the `utils.py` we have duplicated in each software release tests by a more "official API".

This introduce a  "sandalone slapos API" which are helpers around slapos API to create a recursive SlapOS. This can eventually replace implementation of erp5testnode and slaprunner (but there are no plans for that)

/reviewed-on nexedi/slapos.core!64

connection_dict generated by client can be different in details from the
server side, so pass it thorugh a way how it is treat on the server.

Also, as we are going to be compatible with py3, calculate hash from
sorted items of a dict, instead of relying on side effect of py2 "ordered dict"

https://portingguide.readthedocs.io/en/latest/dicts.html#changed-key-order

Test are focused on client side, and the tricky cases are covered, they
somehow contain the protocol of client <--> server comparision.

All tools from the ecosystem shall use the same way to convert between python's
dict and XML.

Additionally stabilise generated XMLs by sorting the dictionary.

A set of utility classes to run a local slapos computer and control
softwares/instances on this computer

Calling computer.updateConfiguration should remove previously defined
partitions that are no longer part of the configuration.

Similar to the way we bypass for simple frontends. This should allow kvm
software promises to pass.

When slapproxy is not using multi-master, shared frontend requests
were never fulfilled. This is problematic because several promises (for
example monitor ones) assert that frontend is instanciated and properly
responding to HTTP requests.
Better-than-nothing approach is to return the URL provided as input,
ie: "Give me a frontend for $URL" -> "OK, just use $URL".

(because it looks strange)

This reverts commit 042bd6bc.

This reverts commit fca2f842.

This reverts commit 7698537e.

This reverts commit 974c3763.

This reverts commit f629cf50.

This reverts commit 7c040914.

BTW, Chinese currency official abbreviation is CNY. Maybe I should
submit the currency_module/CNY to nexedi/erp5 repository

test.erp5.testSlapOSSubscriptionSkins

test.erp5.testSlapOSSubscriptionSkins