Preauth interface gak_fct cleanup

[ghudson@MIT.EDU]

I'm considering making one more change to the preauth interface before
the 1.10 branch, to clean up the gak_fct stuff on the client side.  My
motivations are:

* Avoid exposing a copy of the gak_fct contract, which is kind of
  problematic because it treats as_key as an in-out parameter.

* Reduce the number of parameters to process_fn and tryagain_fn.

* Do a better job of respecting the malloc barrier.

>From looking at existing preauth plugins, I believe that:

* Encrypted timestamp and encrypted challenge just need to get the AS
  key using the enctype, salt, and s2kparams received in etype-info2.

* PKINIT doesn't care about the etype-info2 information, but needs the
  enctype of the AS-REP (to know what kind of key to compute) and
  needs to be able to replace the AS key.

* SAM2 calls gak_fct with an etype from the SAM challenge body rather
  than from etype-info2, and also uses the etype-info2 salt for
  purposes other than getting the AS key.  However, SAM2 is an
  internal mechanism and can cheat, so I'm not worried about its
  peculiarities too much.

* OTP needs to be able to replace the AS key.

* Future preauth mechanisms should not be using the etype-info2
  parameters (other than perhaps enctype) except to compute the AS key
  from a long-term password.  (This came up in discussion about OTP,
  and led to OTP transmitting its own salt and s2kparams for its own
  use of string-to-key.)

What I'd like to do is eliminate the gak_fct, gak_data, salt,
s2kparams, and as_key parameters to process_fn and replace them with
two callbacks:

    /*
     * Get a pointer to the client-supplied reply key, possibly invoking the
     * prompter to ask for a password if this has not already been done.  The
     * returned pointer is an alias and should not be freed.
     */
    krb5_keyblock *(*get_as_key)(krb5_context context,
                                 krb5_clpreauth_rock rock);

    /* Replace the reply key to be used to decrypt the AS response. */
    krb5_error_code (*set_as_key)(krb5_context context,
                                  krb5_clpreauth_rock rock,
                                  krb5_keyblock *keyblock);

Modules would lose the ability to check if the gak_fct output is
already known before invoking it, but I can't think of a real use case
for that.  Modules would also lose the ability to use the etype-info
salt or s2k_params for other purposes.

The get_etype callback would become, I think, half-useless.  When
processing a preauth-required error, the etype comes from etype-info2
and (I think) should only be used for the gak_fct.  When processing an
as-rep, it's the enctype of the encrypted part of the reply, which is
useful for at least pkinit.