Simplify kdb5_ldap_util special princ creation

In kdb5_ldap_realm.c, factor out special principal creation into three
helper functions to reduce the amount of verbiage in kdb5_ldap_create.
Add kiprop/<master-hostname> during KDB creation

To reduce the number of steps in the deployment of iprop, create the
kiprop/hostname principal for the master KDC during KDB creation.
Adjust tests to match the new behavior.

[ghudson@mit.edu: clarified commit message; avoided applying kadmin
flags/lifetime to kiprop principal]

ticket: 7979 (new)
Add flag word to KDB iteration APIs

ticket: 7977 (new)
subject: Enable unlocked KDB iteration
Support write locks in DB2 iteration

Add support to krb5_db_iterate() for requesting write locks in the DB2
back end.

ticket: 7977
Use write lock flag for update_princ_encryption

In kdb5_util update_princ_encryption, instead of getting a write lock
on the KDB surrounding the call to krb5_db_iterate(), use the
iterflags parameter of krb5_db_iterate() to request that it obtain a
write lock around the iteration.

ticket: 7977
Support unlocked iteration in DB2

Add support to the DB2 KDB back end to optionally release the lock
when calling the iterator callback.  This prevents the blocking of
other processes when dumps of large databases are taking place.

Also add support for reversed iteration.

ticket: 7977
Tests for unlocked iteration

ticket: 7977
Ignore iprop deletion of deleted princ

Now that an iprop full dump might not hold a lock around the entire
dump, it's possible that iprop will queue an incremental update while
the dump is in progress.  If a principal is deleted while the dump is
in progress, the dump could omit that principal, yet the deletion
event would still be queued in the ulog.  Ignore that deletion without
generating an error.

This is the same basic change as for ticket #7753.

ticket: 7977
Stop locking around iprop dumps

ticket: 7977
Document unlockiter

ticket: 7977
Support kdb5_util dump -rev again

Restore kdb5_util dump support for reversed dumps.

ticket: 7978 (new)
Correct includes for unlockiter.c

Some platforms (e.g., Solaris) need a declaration of memset() for the
FD_ZERO() macro to work, contrary to POSIX standards.  Add an
inclusion of <string.h> to accommodate them.  Also add <sys/time.h>,
possibly needed by some older platforms, and remove a spurious
inclusion of <sys/socket.h>.

ticket: 7977
In ksu, merge krb5_ccache_copy() and _restricted()

Other than whether or not they limit the creds it stores to the new
ccache based on the principal name of the client for whom the creds were
issued, there's no meaningful difference between what these two
functions do.  Merge them.
In ksu, don't stat() not-on-disk ccache residuals

Don't assume that ccache residual names are filenames which we can
stat() usefully.  Instead, use helper functions to call the library
routines to try to read the default principal name from caches, and
use whether or not that succeeds as an indication of whether or not
there's a ccache in a given location.
Use an intermediate memory cache in ksu

Instead of copying source or obtained creds into the target cache and
changing ownership if everything succeeds, copy them into a MEMORY:
cache and then, if everything succeeds, create the target cache as the
target user.  We no longer need to clean up the temporary ccache when
exiting.
Use a fake temporary cache client principal in ksu

Add a paramter to krb5_ccache_copy() which will provide the principal
name for which the target ccache should be created.  Using a fake value
("_ksu/_ksu@_ksu") when we copy the source user's creds to a MEMORY
cache should prevent us from accidentally selecting it when we make a
subsequent call to krb5_cc_cache_match() to find a location where the
creds should be stored for use while running as the target user.
Make ksu respect the default_ccache_name setting

Move logic for resolving and initializing a cache that we're copying
creds into out of krb5_ccache_copy(), and let the caller deal with it.
Add helper functions to pull the default location from the configuration
and resolve any substitutions in it, and to select or resolve an output
ccache using that location after we've switched to the target user's
privileges.  If the destination is a collection, take care not to change
which subsidiary is its primary.  If the destination is not a
collection, continue to use a per-run cache.

We move the declarations for k5_expand_path_tokens() and
k5_expand_path_tokens_extra() from os-proto.h to k5-int.h so that
they're declared for us to use.
Copy config entries to the ksu target ccache

When we try to screen out expired creds while reading them from one
ccache to eventually store in another, also keep configuration entries.
Use more randomness for ksu secondary cache names

When generating a suffix to append to a ccache name that will hold the
credentials for a ksu-invoked process, instead of using integers
counting up from 1, use the result of base64-encoding six randomly-
generated octets.  Tweak the output alphabet just a bit to avoid using
'+' or '/' in the generated names, the latter of which could really
confuse things.