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.

(cherry picked from commit 7fee58ccadf1b61eec9a8c62f47dac43986e2ad1)

ticket: 7730
version_fixed: 1.12
status: resolved
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.

(cherry picked from commit 4ccc18bc3ddc49d0fd0d2de00ec91c0fa44c53a8)

ticket: 6507
version_fixed: 1.12
status: resolved
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.

(cherry picked from commit f9d6353922393936ab7125d1f04e577857909a99)

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.

(cherry picked from commit 74c1420ea4dffc1105247e362decf608440751ae)

ticket: 7685
version_fixed: 1.12
status: resolved
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.

(cherry picked from commit ec560fac83912abaa15fb158101c8174497081c5)

ticket: 7686
version_fixed: 1.12
status: resolved