Even if the Map had no markers, display some location meaningful instead a point into the occean

  Since we use latitude/longitude, "Region" is irrelelant.

Use correct script.

  Contributed by Romain Courteud

  When upgrade the site, we shouldn't revert the count, else it may lead to duplicated values.

slapos_cloud: fixup be0d00d6

Half commited propertysheets change

   This fixup mostly the status column and introduces type (since it is multiple type entry).

    The uid is kept the same so updateRelatedContent don't need to reindex the related object in this specific case.

   This save us double indexation activities triggerred on different moments.

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 !327

See merge request !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 !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.