[krbdev.mit.edu #7793] preauth context leaks on failure

[Greg Hudson via RT]

A krb5_context object can contain a pointer to a krb5_preauth_context 
object.  This pointer is managed within get_in_tkt.c as follows:

* It is initialized in restart_init_creds_loop().
* It is destroyed before each call to restart_init_creds_loop() except 
for the one in krb5_init_creds_init().  In each of these cases it is 
immediately reinitialized by restart_init_creds_loop().
* It is destroyed when we successfully obtain creds, just before 
init_creds_step_reply() exits.

If we fail to obtain creds, the preauth context will leak.  This can be 
easily observed by running kinit and failing to enter a password (typing 
ctrl-D).  It can also be observed by running kvno -U, because  
s4u_identify_user causes an intentional failure to get initial creds.

We could squash this leak easily enough by destroying the preauth 
context in krb5_free_context(), but it would be better to manage the 
pointer from krb5_init_creds_context.  As things stand, interleaved 
krb5_init_creds_init/krb5_init_creds_step calls using the same 
krb5_context could mess up each others' preauth contexts.