Add option `allow-tcp-connection-on-replica`, set to true by default.

This option corresponds to `skip-networking` in mariadb configuration.
Changing it only takes effect the next time mariadb is restarted; this
does not occur automatically. Instead a script is provided to shutdown
mariadb: bin/mariadb-shutdown-gracefully. Mariadb will then be started
by SlapOS the next time the instance is processed (even when master is
offline).

Leaving this option set currently limits the ability to takoever fully
as a part of the service of a mariadb instance, without SlapOS action:
the value of skip-networking will be controlled by SlapOS, rather than
by the user interacting with the mariadb service.

Deactivate zope promises when the neo is expected to be BACKINGUP,
as this makes the zope process crash, which is currently expected.

Deactivating the zope process entirely in that case is not desired
because reactivating it would require updating instance parameters
and reprocessing the partition. Instead, ideally, the zope service
should adapt to the state of the neo.

Also, move zope service from etc/service to etc/run to make it not
be "on-watch", so that when the neo is BACKINGUP and zope crashes,
the partition does not bang and reprocess continuously. This seems
ok because the promise already asserts the service is running.

When upstream-cluster and upstream-masters are given, also pass --backup
to the neo master so that it converges automatically to BACKINGUP state.

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.

This skips replication bootstrap and requires that all binlogs be still
available on the primary. This is useful when the primary is recent and
does not have a ready backup for bootstrap yet, or when all binlogs are
still available and skipping the bootstrap seems more efficient.

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.

See merge request !1714

Fixes handling failed backups and default_exception_handler.

See merge request nexedi/slapos!1685

Stop using deprecated ssl.wrap_socket, and let unset key-file mean
the key is included in cert-file, as is done in python ssl module.
Also let the server crash if specified cert-file or key-file does
not exist, instead of silently falling back to non-TLS http.

Add 'socketpath' and 'abstract' options for path based unix sockets
and abstract unix sockets respectively.

See merge request nexedi/slapos!1716

See neoppod@f4a5fe3b.