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.

It's also interesting to see what scripts have been generated

Keeping buildout.cfg and .installed.cfg can help diagnosing test
failures.

Directories were ignored by mistake, we found out that several files
that would help us diagnosing problems were missing, because we only
snapshot etc/* which did not snapshot recursive directories such as
etc/promise or etc/service.

Symlinks were copied (the target was copied), because they matched the
isfile check, but if the symlink target was not existent, this caused
errors.

Also rename _snapshot_instance_file to _copySnapshot as it is no longer
treating files only

50 was too much now that we keep snapshots in tests.

supervisor configuration is interesting to inspect in, the same for runners
in run and service directories.

/reviewed-on !170

And display a "logout" button in the page.
Instead display plain renderjs error message

Probably this alarm should move into some other bt5 in future.

Add a mock for absolute_url as the test requires a valid url

The supervisord binary in some environments (like webrunner), seems to not
follow the automatic way to find the configuration file, so instead of relying
on it, just explicitly provide the file.

/reviewed-on !168

Add a mock for absolute_url as the test requires a valid url