Maybe we should use 'parts +=' everywhere in /components/*/buildout.cfg

When looking for emergency user, zope configuration is not fully loaded
yet, thus if we do not set INSTANCE_HOME at startup, it will be wrong.
With this change, setting an "access" file under erp5shared folder will
work properly

In the same time, fix HOME folder to not be in a tmp folder

When looking for emergency user, zope configuration is not fully loaded
yet, thus if we do not set INSTANCE_HOME at startup, it will be wrong.
With this change, setting an "access" file under erp5shared folder will
work properly

In the same time, fix HOME folder to not be in a tmp folder

Add support for "hosts" aliasing in Zope instances.
Add support for SASL relayhost with mandatory TLS encryption.
Add mandatory TSL + SASL authentication, to not be an open relay.
Wrap postfix commands with proper environment instead of symlink +
source-able script.
Add ipv6 listening support (untested).
Drop non-required main.cf configuration options.
Make postifx instance optional (requires postmaster address to be
provided).
Document and rework smtp-related parameters.
Expose an userhosts hostname for smtp server.
Add diversion support (solution to "prod clone sent mails to real customer").
Use etc/run rather than etc/service, for consistency (if it needs to be
changed, it must be changed for all software types).
Hook into syslog and setup local syslog daemon, with logrotate integration.
Update TODO entries.

update cloudooo configuration as well.

For performance reasons, the root partition requests subpartitions during
initialization of sections, whereas such processing should normally be done
during the update/install phase.

The consequence is that partitions may be requested whereas they depend on
sections that fail (usually just temporarily, because of missing returned
parameters in the first runs).

For example, the request of zope partitions depends on the generation of
passwords:

1. password generated (__init__)
2. zope partitions requested (__init__)
3. password saved (install)

As long as a failure happens between 2 and 3, zope parameters are always
updated with a different password.

In the case of NEO, the instanciation of zope partitions currently succeeds even
if the list of master nodes is missing (note that there is a minor bug to fix
here: whenever a NEO storage is not the main one, zope processes may start too
early, and the user may have to restart zopes manually). The 'inituser_done'
file is created but zope processes fail to start if NEO is used as main storage,
and all this happens before the password was saved in the root partition
([neo-0-final] failing to install because 'admins' parameter returned yet).

This was never an issue with ZEO because zopes start successfully at the same
time the 'inituser_done' file is created.

One way to solve this could have been to introduce a dummy dependency between
[neo-0-final] and any other section generating a password. Quite ugly and we
also found non-optimal to use a non-backuped file in the root partition to save
such information, whereas we need anyway to publish them for the user.

Therefore, we introduce a new 'publish-early' recipe for accessing and
publishing desired parameters before any request of partitions. Of course,
these must not be dropped by the usual [publish] section, and to avoid having
to repeating them all manually, we have also added a '-extends' option to the
'publish' recipe.

We use the same technique to autogenerate and configure cluster name for NEO,
which helps us in minimizing the number of params one has to pass for
requesting NEO.

In the 'generate.password' recipe, the 'storage-path' can now be empty, when
there's no need to save the generated password in a file.

Before it was only possible to make an ERP5 cluster connect to a NEO cluster
that was instanciated separately, by passing "name" and "master_nodes"
connection parameters in "storage-dict".

For an internal NEO DB, "name" and "master_nodes" is filled automatically
and you must instead pass a "server" dict, with same parameters as in NEO SR.
Currently, a NEO cluster name must be given. Later, we hope to generate a good
name automatically.

All this was implemented by refactoring NEO & ERP5 SR, with common files.
For the ERP5 SR, the root partition also serves as "root" partition for NEO
partitions: in other words, there's no second empty partition.

erp5-cluster: haproxy, move generic configuration into default section