Rework openldap::server::database interface for the syncrepl parameter

[smortex]

The current syncrepl data type (Optional[Variant[String[1],Array[String[1]]]]) is tedious and error prone (#221, #407). Thanks to data types, we can improve validation at the Puppet level, making it easier for the user to write a catalog that configure replication using the module, and harder to provide invalid OpenLDAP configuration.

Because of the new validation, this PR is a breaking change. The interface is therefore adjusted to mandate an Array of replication configurations, even if a single one is required. This is intended to make the interface simpler.

The provided configuration is now validated with a dedicated Openldap::Syncrepl data type, which is serialized to the previously expected string by the openldap::server::database class and passed to the openldap_database puppet type.

Fixes: #221

Updating your configuration

If you are using the syncrepl parameter, you need to update your manifests when updating the module.

Transform a configuration like:

openldap::server::database { 'dc=example,dc=com':
  ensure   => present,
  syncrepl => 'rid=1 provider=ldap://server2.example.net searchbase="dc=example,dc=com"',
}

openldap::server::database { 'dc=example,dc=net':
  ensure   => present,
  syncrepl => [
    'rid=1 provider=ldap://server2.example.net searchbase="dc=example,dc=net"',
    'rid=2 provider=ldap://server3.example.net searchbase="dc=example,dc=net"',
  ],
}

Into this:

openldap::server::database { 'dc=example,dc=com':
  ensure   => present,
  syncrepl => [
    {
      rid        => 1,
      provider   => 'ldap://server2.example.com',
      searchbase => 'dc=example,dc=net',
    },
  ],
}

openldap::server::database { 'dc=example,dc=net':
  ensure   => present,
  syncrepl => [
    {
      rid        => 1,
      provider   => 'ldap://server2.example.net',
      searchbase => 'dc=example,dc=net',
    },
    {
      rid        => 2,
      provider   => 'ldap://server3.example.net',
      searchbase => 'dc=example,dc=net',
    },
  ],
}

[coreone]

This looks good, but a couple options are missing:

Optional[logbase] => String[1],
Optional[logfilter] => String[1],
Optional[retry] => String[1],
Optional[syncdata] => String[1],
Optional[sizeLimit] => Variant[Integer[0], Enum['unlimited']],
Optional[timelimit] => Variant[Integer[0], Enum['unlimited']],

[coreone]

Added a PR against this branch with the missing fields I found

[smortex]

Nice! Do you think this interface is better and we should go this way?

[Valantin]

Intresting, a simil work can be good for limit to

[smortex]

Intresting, a simil work can be good for limit to

@Valantin I am not sure to follow (missing words?), is it related to the changes @coreone did?

[Valantin]

@smortex I mean, a struct to set olcLimits array similar to what you do to olcSyncprov parameter.

[tparkercbn]

I use the syncrepl feature and thing this PR is great! It will make defining syncrepl entries in hiera much cleaner and easier to define and debug. Thanks @smortex for this work. Hope to see it merged soon :)

[smortex]

@smortex I mean, a struct to set olcLimits array similar to what you do to olcSyncprov parameter.

@Valantin Thanks! I added you as reviewer on #414. Just like syncrepl, I don't use this in my home setup so your experience may help spot mistakes I made.

[smortex]

I think this is ready to ship!