Add scripts in bin directory that can be called manually to apply a
new primary-url (after having edited it in the instance parameters)
by turning a primary into a replica or by making a replica follow a
new primary, all without deleting existing data - so this is useful
when the existing data does not diverge from the new primary.

Being able to start replicating from a new primary without deleting
existing data is convenient, but maybe it's better or sufficient or
both to only be able to tell a mariadb to just destroy its existing
data and re-bootstrap from scratch.

Being able to delete all existing data and start from scratch seems
necessary in any case, but it's not clear that a special feature is
needed for this: maybe it's completely enough to be able to destroy
and re-request the instance through standard slapos operations.

Questions remain for automated usage:

1. One option is to provide a url the user may simply interact with
   (clickable button ...) to call the appropriate script. This kind
   of interaction could also be used to trigger the deletion of all
   existing data for a fresh bootstrap.

2. Another option is that editing the primary-url in the parameters
   results in the appropriate script being called. This makes sense
   as a way to remain in sync with given parameters, although there
   are some drawbacks: the uncertain propagation time, and the fact
   there is no guarantee that the existing data can converge to the
   state of the new primary. This might be grounds to keep all this
   strictly manual.

In any case, this relies already on the propagation of the instance
parameters to input the new primary-url, so it may not be useful at
all for any use-case, manual or automated.

Add a script in bin directory that can be called manually to turn a
replica into a primary. Being able to turn a replica into a primary
is an absolutely necessary feature of replication. It's a necessary
step of a takoever procedure.

Questions remain for automatisation. One option is to provide a url
the user may simply interact with (clickable button ...) to trigger
the script, that may also be used automatically as part of a larger
takoever procedure.

Triggering the change to primary by editing the instance parameters
- such as by removing the replication-related parameters - does not
seem best: one immediate drawback is the uncertain propagation time
of instance parameters; another is the reliance on the availability
of the SlapOS master to trigger a usually time-sensitive operation.

Allow requesting a mariadb set-up to replicate another mariadb:
- bootstrap-url: bootstrap from a statically served backup file
- primary-url: replicate from a primary mariadb

This happens in mariadb first initialization, when no data exists yet.
That way existing data in a non-replicating mariadb cannot be deleted
by setting the replication parameters after the fact.

A promise checks that the state (replica / primary, replication source)
of the running mariadb matches the requested state; but if it doesn't,
the mariadb will not automatically converge without human intervention
if ~/srv/mariadb data directory already exists, to avoid deleting data.

This service does on-the-fly modifications on the running mariadb that
can conflict with and break replication and are anyway unneeded in the
replica.

Maybe this service should be dropped entirely and its functionality be
implemented another way.

Use a generated password and publish its url.

Remove

```
[gcc:python2]
part = gcc-8.5
```

from neoppod/software-common.cfg and dream/software.cfg as it causes
gcc being pinned to a different version before and after rebootstrap
when the initial python version is not Python2.

This reverts dc91e5d4.

When use-ipv6 is enabled, make mariadb publish an url of the form:
  `mysql://user:password@[ipv6]:port/database`

instead of:
  `mysql://user:password@ipv6:port/database`

which results in the zope instances crashing during processing
due to urlparse.urlsplit failing to parse the url.

Make it possible to mock any specific cron entry.

Those are candidates to be shared by some other place, like slapos testing.

See merge request !1693

Following advice from https://luajit.org/download.html use recent commit id,
but rely on github archive.

Drop obsoleted patch, enforce --with-shared-termcap-library

Also use directly archive with patches.