krb5_cc_cache_match() searches all ccache collections for a ccache that
has credentials for a given principal name. This includes MEMORY
ccaches, which means it can find the same ccache as is referenced by a
GSS cred handle given to gss_store_cred(), which means that
gss_store_cred() can fail.
For now we work around this by including a private variant of
krb5_cc_cache_match() that only searches the default ccache, not all
collections. Eventually we should ensure that krb5_cc_default() also
searches all collection-type (other than MEMORY) ccaches for a default
credential, then we can go back to using krb5_cc_cache_match() (though
we'll need to make sure that MEMORY is searched last or not at all).
Implement the GSS-API credential store API extensions defined by MIT here:
https://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions
Note: we kill off gss_acquire_cred_ext() here. This was never a public API,
although mechanisms could have implemented it and I briefly used it in my
BrowserID prototype mechanism. gss_acquire_cred_ext_from() occupies the place
in the dispatch table where gss_acquire_cred_ext() used to, but this structure
was never visible outside Heimdal (i.e. it is only used by internal
mechanisms);
(Mechanisms that need to accept arbitrary key/value dictionaries from
applications should now implement gss_acquire_cred_from().)
