[krbdev.mit.edu #7360] hypothesized trigger conditions

[Tom Yu via RT]

libkadm5 locks only the policy database when updates to the policy
database.  One possible trigger condition is:

* create_principal gets write lock on policy db to update policy
  refcount

* krb5kdc races against this, trying to read-lock both principal db
  and policy db (krb5_db2_get_principal gets locks on both)

  ** the principal db lock succeeds, but policy db lock fails

  ** error path in krb5_db2_lock calls krb5_db_unlock, which fails to
     unlock the non-locked policy db, and due to this bug, skips the
     code to unlock the principal db

* krb5kdc ends up with a persistent read lock on the principal db

Another possibility is lockout updates by the KDC racing against
policy lookups (from password changes) by kadmind.