Fix propagating of configdn, configpw, monitordn, monitorpw into

the slapd.conf file.

Using a parameter, as default for another paramter as it is done in the 
server.pp file for above 4 named parameters, is not going to work as intended.
This will basically end up with 4 empty strings that get used in the template file.

Also, be more cautious, when, especially the *pw variables get
written to the file. Further, the suffix= line in the database config
section is not allowed:

Basically fixing error messages like this with enabled config and monitoring
databases:

543e1cc9 /etc/openldap/slapd.conf: line 23: suffix <cn=config> not allowed in config database.
543e1cc9 /etc/openldap/slapd.conf: line 23: <suffix> handler exited with 1!

with rootpw under database config
543e1d10 line 25 (rootpw ***)
543e1d10 /etc/openldap/slapd.conf: line 25: <rootpw> can only be set when rootdn is under suffix

with rootpw under database monitor
543e1dc6 line 38 (rootpw ***)
543e1dc6 /etc/openldap/slapd.conf: line 38: <rootpw> can only be set when rootdn is under suffix

For that last reason, the suffix= line in the config database
is commented out, as it is done for the monitor database already.

Unfortunately the setting of the parameters seems a bit confusing, but since puppet doesn't allow
re-assigning of variables, I had to work around it. 

my tests are done with openldap-2.4.40, and without explicitly setting a configdn or monitordn, because I want to have the same as the rootdn. But at least my changes make this now work for me having a config and monitoring database backend.


I'm also not a big fan of the result. But the documentation about the configdn, monitordn, configpw, monitorpw parameters, a bit more up in the file, states that the default values are taken from rootdn and/or rootpw respectively.

This is broken how it was implemented before the proposed change.

having 
```puppet
class blah (
  $param1,
  $param2 = $param1,
) {
...
}
```
At least param1 cannot be used to give param2 a default value, so this is broken here.

What I've done is to try to implement following the documentation.
The problem is the Default values, to the rootdn/rootpw. The implementation is a bit complicated, because variables cannot be reassigned. If it would be OK to drop this requirement to default to the rootdn and rootpw, 
then the whole logic block would become much easier. 
Hope it either clarifies, or let me know if it would be OK to drop that requirement with the default values, and I could make it easier.

Sebastian