[booth] `pcs booth ticket add` shall be accompanied with native validation

[jnpkrn]

Pcs currently allows for invalid configuration for booth to be
generated, such as when (under simplification) expire period
is lower than or equal to 110 (see boothd(8)), resulting in:

Jan 09 17:10:21 virt-184 booth: [13184]: error: TICKET02: total amount of time to retry sending packets cannot exceed renewal frequency (5000*(10+1) >= 50000)
Jan 09 17:10:21 virt-184 booth: [13184]: error: in config file line 8

The suggested way to address that on pcs side:

1. working generated contents of configuration file is output
   to a side, temporary and possibly persistence-unbacked location
   (/run/pcs/booth/virt-184/booth-booth.conf for instance)

2. actual validation by booth is performed like this:

     booth status -c /run/pcs/booth/virt-184/booth-booth-FDs3k.conf

3. the only complication possible -- the above may be launched on
   node that is not currently in possesion of cluster-wide
   booth-booth-ip resource (or equivalent), hence this would be
   shown as an error, resulting in exit status of 1:

Jan 09 17:43:17 virt-184 booth: [16750]: error: Cannot find myself in the configuration.

to workaround this, a cheap trick -- inject localhost address(es) --
could be applied; note that it's important to inject it in a way
that the resulting number of the actors will be odd, so e.g.,
add:

site = 127.0.0.1
site = 127.0.0.2

of course, this addition would need to be undone again when
the configuration as such passes, removing the working file
(/run/pcs/booth/virt-184/booth-booth-FDs3k.conf) behind

[tomjelinek]

Validating booth configuration by the booth itself is a great idea. However, I don't quite like the fact that the config must be tampered with prior to validation. Basically, it means we would be validating different config than we would distribute to clusters. That just doesn't feel right.

Once booth provides means for validating an actual config, we will reconsider this feature.

Thanks.