This reverts commit a8f83ef9 and the
other places where this pattern was copied.

If some non verified connection is being made, let's be honest and don't
hide it to user.

In the commit dc559dad specific exceptions
has been exposed to caller, but in case of SLAPOS_TEST_DEBUG enabled unusal
exception is raised.

This commit improves the situation so that behaviour is consistent neverthless
the SLAPOS_TEST_DEBUG.

This reverts commit 71fd0fab.

All Zelenium tests are failing because of this change.
Revert until all tests are fixed.

The change was missing in the commit 439786ba.

Filling the service worker is not supposed to take so much time

The inventory catalog uses second for precision.
Ensure all test movements are created in different seconds.

See merge request nexedi/slapos.core!334

The state of Software Release being cleaned up or not is really never
known, so simply drop the concept.

Use case to cover, is some developer having upgrade_scope=auto set and
installing archived SRs - it IS expected that such SR would be cleaned
if not used.

The allocation_scope of Compute Node is as important, as Compute Node
owner regarding the software management itself.

Add a test where the binary is compatible but the signature is unverified

Avoid catching interruptions and system calls during exception handling

Get all binaries for the requested SR
Indicate which are verified by the certificate list

Leave string interpolation to the logging method

Use `gcc -dumpmachine` instead of `platform.machine()` to discriminate
architecture

Use libnetworkcache to list only binaries with verified signature

See merge request !352

See merge request nexedi/slapos.core!346

See merge request !347

Improvements:

 * allow to destroy any kind of instance
 * damage software release to avoid change propagation
 * provide more information in the UI for the OSS Operator
 * stabilise field and action naming
 * allow to rename and destroy only stopped instances

For the OSS Operator it's important to have a safe way to rename and stop
instances, especially in context of the Instance Tree management.

This action is more advertised then rename and destroy, which has much
more drastic consequences.

Fix a missing dependency in 1.7.0 on python2

Minor version was increased because "slapgrid: Process promises with
instance python" brings full support of using slapos node on python3
also when using software on python2

Support a syntax like:

      slapos request \
        --node=computer_guid=local \
        --parameters-file=~/request.json \
        ERP5 \
        https://lab.nexedi.com/nexedi/slapos/raw/1.0.145/software/erp5/software.cfg

to request an instance with parameters in ~/request.json file.

This also teach slapos.core about the instance schema, which makes it possible to
understand the serialisation, so that we no longer need to use `_ = json.dump(params)`
to encode parameters.

This also emits a warning when requesting with parameters which do not match the schema.


See merge request !215

Because json is unicode in python2, pretty-printing the parameters would
display something like {u'foo': u'bar'}. Encode these unicode strings on
python2, so that it looks like {'foo': 'bar'} on both python2 and python3

This is more readable

Support a syntax like:

      slapos request \
        --node=computer_guid=local \
        --parameters-file=~/request.json \
        ERP5 \
        https://lab.nexedi.com/nexedi/slapos/raw/1.0.145/software/erp5/software.cfg

to request an instance with parameters in ~/request.json file.

This automatically understands the serialisation, when software uses json-in-xml
serialisation, no need to use `_` argument with the encoded json.

This allows easily serving a directory content with a server like this:

    from six.moves import SimpleHTTPServer

    class FileHTTPServer(ManagedHTTPServer):
      working_directory = profile_dir
      RequestHandler = SimpleHTTPServer.SimpleHTTPRequestHandler

See merge request nexedi/slapos.core!351

SlapOS ticket RSS have one entry for each ticket, with the content of
the latest event as description, but when using a feed reader application,
we'd like to have a new entry for each message posted to the ticket, to
be notified that a new message was posted.

Feed reader applications fetch the RSS and have to determine if each
entry is already in their database or not. In a scenario like below, we
observe different behaviors for different applications:

  1. a user open a ticket "help" with a first message "I need help !".
    The RSS entry for this ticket is:

    <item>
      <link>https://slapos.example.com/#/support_request_module/1</link>
      <title>Help</title>
      <pubDate>Mon, 01 Jan 2001 10:57:10 +0100</pubDate>
      <description>I need help !</description>
    </item>

   => feed reader fetches the RSS and add a new entry with title "Help"

  2. support operator reply with a second message "how can I help you ?"
    The RSS entry for the ticket becomes:

    <item>
      <link>https://slapos.example.com/#/support_request_module/1</link>
      <title>Help</title>
      <pubDate>Mon, 02 Jan 2001 08:32:12 +0100</pubDate>      <== this is different
      <description>How can I help you ?</description>           <== this is different
    </item>

now depending on the implementation of the feed reader, it will either:

 - add a new entry, this is the best behavior. In the RSS readers I tested,
  liferea and newsboat do this. Probably they consider that the entry is
   different because it has a new pubDate and/or description.
 - update the existing entry "in place" - this is not so good, because
  this does not appear as a new entry and the original message is no
  longer in the RSS reader. TinyTinyRSS behaves like this (at least in
  version 17.4, which is a bit old)
 - consider they already have the entry and don't do anything - this is
  even worse, because user can not see there was a reply. FreshRSS
  behaves like this.

A RSS for tickets will always have the problem that the feed reader must
refresh often enough if we want to have a copy of all messages in the
feed reader (and that's why ERP5 CRM's uses a RSS of Events and not
Tickets), but we can make this situation better by using guid on messages.

By constructing a guid [1] that will become different every time a new
message was posted, feed readers consider each item as a a new, different
entry. At least this is the case for all the feed reader I tested, except
ERP5 builtin feed reader which only consider the `link` attribute.

Strictly speaking this implementation has a "problem" that these guids
are not permalinks, but I believe that's something we should address in
erp5_rss_style (if guid does not look like an URL, set isPermalink="false"),
but in practice it does not seem to be a problem.

1: https://validator.w3.org/feed/docs/rss2.html#ltguidgtSubelementOfLtitemgt