On some test machines, we saw test failures because openssl version mismatch:

```
Traceback (most recent call last):
  File "/srv/slapgrid/slappart14/srv/testnode/cqg/soft/18d28ecd49e5e0f732e2ce0c00c57519/parts/slapos.core-repository/slapos/testing/testcase.py", line 227, in installSoftwareUrlList
    checkSoftware(cls.slap, software_url)
  File "/srv/slapgrid/slappart14/srv/testnode/cqg/soft/18d28ecd49e5e0f732e2ce0c00c57519/parts/slapos.core-repository/slapos/testing/testcase.py", line 211, in checkSoftware
    raise RuntimeError('\n'.join(error_list))
RuntimeError: ./parts/proftpd/libexec/mod_auth_web.so:
./parts/proftpd/libexec/mod_auth_web.so: /usr/lib/x86_64-linux-gnu/libssl.so.1.1: version `OPENSSL_1_1_1' not found (required by /srv/slapgrid/slappart14/srv/testnode/cqg/inst/test0-0/tmp/shared/curl/724c785f86fff6993ff24ef745d4dbb9/lib/libcurl.so.4)
```

What we see in this traceback is that the version of openssl used was the one from system ( in `/usr/lib/` ), which should not happen because we are using setting rpath to slapos libraries. We had a test checking for missing rpath that could not resolved, but our test did not catch missing rpath that can be resolved on a system library, which is also wrong because this system library might be a different version like here or even be missing.

/reviewed-on nexedi/slapos.core!172

Except a short whitelist of system libraries, we should have always set
rpath so that the slapos version of the library is used.

We had issues with components which where compiled with slapos version
of openssl but linked without rpath. At runtime they were using system
openssl.

Rewrite our complex grep shell pipeline in python, with a function
parsing ldd output so that we can check not only for not found dynamic
libraries, but also for libraries that are found outside of slapos
library dirs.

This also fixes problems that this grep pipeline did not support paths
with spaces in their names.

Each time slave partition changes (it is added or updated) the master
partition timestamp has to be recalculated.

/reviewed-on nexedi/slapos.core!176

Fix long lines, incorrect type annotations and adjust a bit to make mypy
happy.

Sometimes instanciation fail because some service do not start and the
"check port listening" promises fail. In this case, it's very important
to also have the partition content to see what's in the log files.

/reviewed-on nexedi/slapos.core!175

the pagination doesn't work because
SoftwareInstance_getConnectionParameterList returns always all
parameters.

/reviewed-on nexedi/slapos.core!174

/reviewed-on nexedi/slapos.core!173

  'since' should be unmutable.

Also define a short cache, to prevent creation explosion

Allow it report the message and creation date, which can be usable on other contexts.

slapos_jio: fix AccountingTransaction_getPaymentStateAsHateoas after f512ad84

Implementing improvements discussed in nexedi/slapos@1a5df533 (comment 93275) and on  nexedi/slapos.core!150 (comment 92471) 

We now only store slapos logs one per `setUpModule` for software and `setupClass` for instances.

There's no de-duplication, but it's still a bit big.

/reviewed-on nexedi/slapos.core!156

Include additional states to handle additional steps when handle a subscription requests.

started: Once Subscription is started, it means that instance is ready and user was notified
stopped: Once Subscription is stopped, it means that instance is destroyed but not all invoices were payed. Subscription is about to be Delivered (Closed).

This prevents things get broken.

Once the Computer/Hosting Subscription is transferred using Internal Packing List, the associated installation and instance should acquire security from the respective context.

slapos_crm: Fix up test, alarm is only call for Support Request associated to a Hosting Subscription

Tickets should be automatic suspended if they aren't supposed to be responded by the user.

This API is used by anonymous so we convert the query for the rely on shadow person security

Promise can appear and disappear, and pyc or pyo files can stay in the folder,
so try hard to remove those stale files.

/reviewed-on nexedi/slapos.core!169

To isolate log files per test in the snapshots

Log files from slapos node software are large and they are always the
same after each test method, so it does not make much sense to store
them for each test method snapshot, because we only run slapos node
software at setupModule step.

Log files from slapos node instance are smaller, but it's also not
needed to make a snapshot after each test, because we only run slapos
node instance at setUpClass step.

To prevent duplication, store slapos log files only at setupModule (for
software) and at setUpClass (for instance).

Also store log slapos log files in all the steps that can fail in
_cleanup.

Everything in etc can be interesting while investigating issues in
test, also it should not be too big.