Some preauth mechanisms, such as PKINIT and OTP, do not require a
client long-term key to work.  Although our kadmin system does not 
currently allow principal entries to exist without long-term keys, it 
can be done with a custom KDB back end or an externally-maintained LDAP 
KDB.

We need three changes to make this work properly:

* We should not offer encrypted timestamp or encrypted challenge as 
preauth mechanisms if there are no client keys.

* If there are no client keys, we should not ship an empty etype-info or 
etype-info2 list to the client.  An empty list is prohibited by RFC 4120 
for etype-info2 (there's a sequence length restriction in the ASN.1, 
which we don't enforce in our ASN.1 code) and only serves to cause our 
client code to error out prematurely.

* If the KDC cannot find a client long-term key while preparing the 
reply, it should give preauth mechs a chance to replace the reply key 
before erroring out.