- There's now a single software type 'neo' (in addition to the default)
  which contains:
  - 1 master
  - 1 admin
  - a configurable number of storage nodes, that share the same MySQL server
- Review of parameters to configure MySQL server.
  (innodb_buffer_pool_size is important)
- Check of meaningless values of 'replicas'.

This problem was not found during development because I used a local checkout
of slapos cookbook and these files were not downloaded but directly copied
from the disk.

In zc.buildout, the Download class should be changed to use something that
respects umask, instead of 'tempfile.mkstemp'.

- switch-softwaretype recipe is not merged to master yet so we must
  slapos-cookbook in develop mode, like for ERP5.
- Recognize "RootSoftwareInstance" as default software type for compatibility.

Contrary to ERP5, there's no mysql-update service:
- this simplifies the SR
- after reading the MySQL documentation, the automatic use of mysql_upgrade
  is quite frightening:
  « You should always back up your current MySQL installation before performing
  an upgrade. »
  « After running mysql_upgrade, stop the server and restart it so that any
  changes made to the system tables take effect. » (which is currently not done
  by the recipe)
- the future of NEO is an embedded DB like libmysqld

New 'slapos-kill' from slapos.toolbox is used instead of 'killpidfromfile'
This is required for NEO which does not write any pid file.

The inline recipe for ERP5 has been improved and converted into recipe,
which is reused for NEO.

Templates are instanciated only if they're used, so no need anymore to
wrap them with:

  {% if slap_software_type == software_type -%}
  ...
  {% endif %}