With recursive instances, it was possible that the slapos.cfg introduce a
kind of loop and this was checking again and again the same folders.

Fix this by keeping track of the visited instance root and not visit the
same instance root twice.

See merge request nexedi/slapos.core!327

See merge request nexedi/slapos.core!326

This test was using time.strftime which uses the current machine timezone,
but collection is done in UTC timezone, so the test was sometimes failing
because the strftime('%Y-%m-%d') was another day than the same time in
UTC time zone.

This test https://erp5js.nexedi.net/#/test_result_module/20210811-96D6B55F/8
for example had the problem. By using faketime and TZ=Europe/Paris
environment variable, the same problems reproduced locally 100% of times.

The fix is to always use datetime.utcnow().strftime('%Y-%m-%d'), to not
depend on the timezone.

Don't buffer output and use a separate thread to read subprocess process output
and send it line by line to logging, instead of reading from the main thread
which output lines with a delay.

fixes https://erp5js.nexedi.net/#/bug_module/20210311-90BA30

To consider if a shared part is used, we consider all files named `slapos.cfg`
in the instance and try to parse them as a slapos config file.
The problem was that as soon as a file can not be parsed as a slapos config
file, we did not continue to evaluate other `slapos.cfg` files. It was a
`return` where it should have been a `continue`.

This was especially incorrect, because when we have recursive slapos, we
usually have a working copy of slapos repository, which contain
`stack/slapos.cfg`, which is not a valid slapos config file.

As a result, when a top level shared part was used in a software installed
in the recursive slapos from a theia or slaprunner instance, this shared
part was not detected as used and could have been deleted.

The fix consist in checking all `slapos.cfg` files. This will make slapos
node prune command probably much slower, because it will really iterate on
all files now. Anyway this was fast because it was wrong.

See merge request nexedi/slapos.core!324

  This changes aims minimize the unecessary accessed to master while the
  instance is going to be skipped to process or won't post informations to master.

  This in best cases reduces access from 1+n to 1 while n = number of used partitions.

  Fixed up after the (revert)

  The suffixes present on the come_from are incompatible with the addition done by portal_password

   This originally is a patch on erp5 repository, but moved into a single bt5 for better mantainence.

See merge request nexedi/slapos.core!322

The depot_tools package used to build Chromium (see
nexedi/slapos!1014) installs some Python
libraries (NumPy and PIL) with shared objects that don't have RPATH set.
These shouldn't actually be used when running Chromium, but they cause
the testing framework to complain about missing libraries.

   Move all methods related to catalg from slapos_cloud into this BT5, so we can force updates/installation on every upgrade.

See merge request nexedi/slapos.core!320

This reverts commit 202a9bcd because it caused
some test failures.

   This prevents diff while commit others things

Forgot to mark the version.

It's a release which fixes changelog for badly released 1.6.15

  This changes aims minimize the unecessary accessed to master while the
  instance is going to be skipped to process or won't post informations to master.

  This in best cases reduces access from 1+n to 1 while n = number of used partitions.

  Since the status is part of the getFullComputerInformation, once it
changes state reindex the instance. This is required to prevent the
message be outdated while check for anomaly.

[collect] section was put in the middle of [networkcache] section resulting
with badly working fresh slapos-node installations using the example as a
configuration template.

This fixes commit 2da17657

See merge request !318

OfficeJS's user blocking third party cookie will at least stop entering their credentials many times for nothing

   If the mariadb is more recent (and consitent) them the ZODB, it isn't needed to full reindex since all
   changed objects are visible in the catalog. So it is safe enough only partially reindex.