Changes to use a single database for dogtag and IPA

New servers that are installed with dogtag 10 instances will use
a single database instance for dogtag and IPA, albeit with different
suffixes.  Dogtag will communicate with the instance through a
database user with permissions to modify the dogtag  suffix only.
This user will authenticate using client auth using the subsystem cert
for the instance.

This patch includes changes to allow the creation of masters and clones
with single ds instances.
Fix schema replication from old masters

The new merged database will replicate with both the IPA and CA trees, so all
DS instances (IPA and CA on the existing master, and the merged one on the
replica) need to have the same schema.

Dogtag does all its schema modifications online. Those are replicated normally.
The basic IPA schema, however, is delivered in ldif files, which are not
replicated. The files are not present on old CA DS instances. Any schema
update that references objects in these files will fail.

The whole 99user.ldif (i.e. changes introduced dynamically over LDAP) is
replicated as a blob. If we updated the old master's CA schema dynamically
during replica install, it would conflict with updates done during the
installation: the one with the lower CSN would get lost.
Dogtag's spawn script recently grew a new flag, 'pki_clone_replicate_schema'.
Turning it off tells Dogtag to create its schema in the clone, where the IPA
modifications are taking place, so that it is not overwritten by the IPA schema
on replication.

The patch solves the problems by:
- In __spawn_instance, turning off the pki_clone_replicate_schema flag.
- Providing a script to copy the IPA schema files to the CA DS instance.
  The script needs to be copied to old masters and run there.
- At replica CA install, checking if the schema is updated, and failing if not.
  The --skip-schema-check option is added to ipa-{replica,ca}-install to
  override the check.

All pre-3.1 CA servers in a domain will have to have the script run on them to
avoid schema replication errors.

https://fedorahosted.org/freeipa/ticket/3213
Use correct Dogtag configuration in get_pin and get_ca_certchain

Some install utilities used Dogtag configuration before Dogtag
was configured. Fix by passing the relevant dogtag_constants
where they're needed.
Update certmap.conf on IPA upgrades

This brings /etc/dirsrv/slapd-REALM/certmap.conf under IPA control.
The file is overwritten on upgrades.

This ensures that the cert for the ipaca user is recognized when
ipa-ca-install is run on older masters.
Properly stop tracking certificates on uninstall

Stopping certificate tracking was done as part of the PKI DS uninstall.
Since with the merged DB, thePKI DS is not used any more, this step
was skipped.
Move certificate untracking to a separate step and call it separately.

Also, the post-uninstall check for tracked certificates used the wrong
set of Dogtag constants. Fix the issue.
Filter suffix in replication management tools

With the new unified Dogtag10 LDAP database, PKI-CA data and the
agreements themselves are now in the main LDAP instance.

Replication management tools now need to properly filter replication
agreements based on the suffix to avoid clashing of agreements of
different types.
Provide 'protocol' argument to IPAdmin

The ancient IPAdmin class used some heuristics to determine the protocol
to connect with (ldap, ldaps, or ldapi). In turn, some calling code used
questionable mechanisms to get the correct protocol: in
ipaserver/install/replication.py, the CA cert was either passed to the
constructor or added to the class afterwards, to get ldap:// or ldaps://.

Add an explicit protocol argument and only fall back to backwards-compatible
guessing if it is not given.
Make ipa-csreplica-manage work with both merged and non-merged DBs

The ipa-csreplica-manage tool often assumed that the port numbers are the
same on both sides of a replication agreement.
This assumption doesn't hold in a cluster with both old-style hosts and
ones with merged DBs.

When managing agreements, determine the port with the PKI (or merged) DS
on each master, and use it.

Also, in CSReplicationManager, always use starttls rather than ldaps://.