Use a single global dump for iprop full syncs

Use a global dump (the default dump file) for full syncs for iprop.
When a slave asks for a fullsync we kprop the existing global dump to it
if that is good enough, else we dump the DB and send the new global
dump.

Before this change kadmind would run kdb5_util dump -i... each time a
slave asked for a full dump.  This was done in a sub-process,
thankfully, but it was still a waste of time and storage (e.g., if one
has a huge KDB).

Also, long dump times might cause a slave to give up (the timeout for
this is now configurable).  But since iprop dumps bear a serial number
and timestamp and since slaves will resync from that point forward, it
doesn't matter if the dump we send a slave is fresh as long as it is
fresh enough (i.e., that its sno and timestamp are in the ulog).

Also:

 - Rename dumps into place instead of unlink, create, write (but we
   still keep the dump ok files for backwards compatibility).

 - Fix a race condition relative to the kadmind side's starting of
   the full sync's kprop (which might otherwise trigger often now that
   kadmind does not dump the KDB every time a slave asks for a full
   resync).
Cleanup dump_db()
Fix kdb5_util dump locking issues

See: rt #7377
ipropd_svc.c DPRINT improvements

Make DPRINT a varargs macro and add some new debug prints.
Add -p, -F, -C options to kadmind

New options:

    -p path-to-kdb5_util
    -C path-to-kprop
    -F dump-file

These are needed for testing without first having to install.
Correct docs re: kpropd usage w/ iprop
Deprecate kpropd -S option
kdb5_util load needs iprop safety net
Add -R option to kproplog to force full resyncs
Remove MAX_ULOGENTRIES

If a master KDC uses only a 64-bit libkadm5srv then there is no reason
to impose any limit on ulog size: the practical maximum will be given by
the filesystem and available storage space.

Even when using a 32-bit libkadm5srv the maximum practical ulog size
will be found easily enough when mmap() fails.
Prep k5test.py for iprop (add start_kpropd(), ...)

Add a start_kpropd() method to K5Realm and make start_kadmind() use the
kadmind -p, -C, and -F options.
Import Greg Hudson's iprop test and get it closer
Make kadmind iprop never return UPDATE_BUSY

Currently kadmind allows slaves to poll for updates as often as they
like, but not within 10s of the last update.  This means that iprop will
appear to fail to synchronize the KDC at any site whose master KDC
processes at least one write transaction every 10 seconds consistently.

The original intention must have been to throttle iprop clients (slave
KDCs) that poll too often.  But UPDATE_BUSY as implemented is not that,
and implementing a throttle would be difficult (requires keeping state
in a table) and mostly useless (admins can manage their poll timers just
fine without a throttle in kadmind).
Remove "kpropd: " from logs; always openlog()
Cleanup some debug/syslog msgs and C style
Stop localizing log msgs; debug msgs to stderr
Remove an old, incorrect comment in kpropd.c

We absolutely do not want a parking brake on the kprop protocol as
described in the comment being removed.  Instead the kprop command
should be fixed so it doesn't die on error (assuming it even still does
or ever did, neither of which I've checked).
Add comment about possible kprop perf enhancement