Fix race in util/profile/Makefile.in

$(BUILDTOP)/include/profile.h was being updated by two different
rules, which could collide with make -j.  Use a dependency from
includes instead of a redundant rule.
Fix typos in kdb5_util master key command outputs

kdb5_util list_mkeys was beginning lines with "KNVO" instead of
"KVNO".  kdb5_util purge_mkeys was displaying "follwing" instead of
"following" for both dry-run and normal cases.

ticket: 7730 (new)
target_version: 1.12
tags: pullup
Use active master key in update_princ_encryption

kdb5_util update_princ_encryption should update to the active master
key version, not the most recent.

ticket: 6507
target_version: 1.12
tags: pullup
Reload master keys to find active mkey if needed

Refactor krb5_dbe_find_act_mkey and make it reload the master key list
if it doesn't find a master key matching the active mkvno.

ticket: 7685
Don't cache active master key list in kadmind

"kdb5_util use_mkey" should not require a kadmind restart to take
effect.  At the cost of fetching the K/M principal once for each key
change operation, make kadmind use the current active master key list
for each operation.

ticket: 7685
target_version: 1.12
tags: pullup
Correctly activate master keys in pre-1.7 KDBs

Starting with 1.7, databases are created with actkvno tl-data in the
K/M entry which gives the initial master key version an activation
time of 0.  A database created before 1.7 will not have this tl-data,
but we should behave in the same way as we do for a more recent
database.

Move the actkvno list synthesis code from krb5_dbe_fetch_act_key_list
to krb5_dbe_lookup_actkvno so it applies to kdb5_util commands as well
as libkadm5.  Synthesize the same list as we would have initialized
the KDB with, with an activation time of 0 for the earliest master
key.

ticket: 7686
target_version: 1.12
tags: pullup
Add master key rollover tests in k5test framework

Add a new script t_mkey.py using the k5test framework.  Test the fixes
for #6507, #7685, and #7686 as well as basic functionality and
old-stashfile compatibility.

dump.16 was created by running "kdb5_util create -s -P footes" and
"kdb5_util dump dumpfile" with krb5 1.6.  The key from the resulting
stash file was extracted and placed in the struct.pack() call in the
new test script.
Remove old master key tests

Remove tests/mkeystash_compat and tests/mk_migr.  These are superseded
by t_mkey.py, with two exceptions:

tests/mk_migr included tests for password history across master key
rollovers.  Historical keys are encrypted in the kadmin/history key
(which is accessed like any other key), so there isn't a specific need
to test this unless we implement #1221.

tests/mk_migr had provisions for testing master key rollover with the
LDAP KDB module.  All master key logic used in the LDAP KDB module is
shared with the DB2 module in lib/kdb, so there is no specific need to
test this combination.
Simplify kdb5_list_mkeys actkvno list retrieval

After recent changes, krb5_dbe_lookup_actkvno cannot yield an empty
list and cannot return KRB5_KDB_NOACTMASTERKEY.
Reset key-generation parameters for each enctype

In add_key_pwd, initialize s2k_params to NULL inside the loop over
enctypes instead of outside the loop, so that if the afs3 salt type
is used it does not contaminate later enctype/salt pairs in the list.

ticket: 7733
tags: pullup
target_version: 1.12
Add tests for different salt combinations

Create a principal with a pair of enctypes using different salt types.
Confirm that the non-default salt type appears only once in the principal's
key list.

Also verify that the afs3 salt type is rejected by non-DES enctypes
The afs3 salt type is for compatibility with AFS-3 kaservers, which
are roughly krb4.  As such, it only makes sense for single-DES
enctypes.  The PBKDF2 and arcfour enctypes correctly reject the
key-creation parameters from the afs3 salt, but triple-DES currently
does not.