RFH: Add prosody service

["Clément Lassieur" <clement@lassieur.org>]

Hello,

I'm actually working on the Prosody service, and I am struggling with a
few things.  What I did works, but some configurations are probably
missing.  I'm not sure I'm doing it the right way, so I would appreciate
a few comments before I go further.

Here is how a typical .lua Prosody configuration file looks like:

-- global section --

global-1 = ...
global-2 = ...
common-1 = ...
common-2 = ...
common-3 = ...

-- virtualhosts section --

Virtualhost domain1
  common-1 = ...
  common-2 = ...
  common-3 = ...

Virtualhost domain2
  common-1 = ...
  common-2 = ...
  common-3 = ...

Settings that are in the global section apply to all virtualhosts.
Settings under each Virtualhost entry apply only to that virtualhost.

So in Scheme, I implemented this as a prosody-configuration
(representing the whole file), containing:
  - global settings,
  - common settings,
  - a list of virtualhost-configuration.

Here are my problems.

A. A virtualhost-configuration has a lot in common with
   prosody-configuration, and I don't want to repeat stuff.

B. Common settings should have a default value in prosody-configuration,
   and be disabled by default in the list of virtualhost-configurations.

I found two ways to solve this:

1. One uses "eval" to transform the input of "define-configuration" into
   a list that I can build from other lists.

2. The other uses a macro that takes define-configuration's input, plus
   a tag (called target) describing whether it's a global, common, or
   virtualhost specific field.  Then the macro calls
   define-configuration many times, each time with a subset of the
   original input, filtered with a specific tag ("global",
   "virtualhost") plus the "common" tag.
   (Its name is define-all-configurations.)

I prefer the first one because it is more readable, but I have been said
in this thread:
http://lists.gnu.org/archive/html/guix-devel/2016-11/msg00993.html
that it is bad programming style.

So I will send two patches, one with the first way and the other with
the second way.  Maybe none of them will be good, don't hesitate to tell
me.  I'm willing to do any changes you'll want.

I did not talk about Components so to simplify things, but its quite
like a Virtualhost, in that it can have common settings too.

There's another issue: how to represent fields that we don't want to
serialize (see problem B).  I define a macro (define-maybe) that adds to
a field the possibility to have the value 'disabled.  But there are
plenty of other ways to do, I could do differently, just tell me.  There
is this thread talking about it:
http://lists.gnu.org/archive/html/guix-devel/2016-11/msg01024.html.

-- 
Clément Lassieur