See discussion in #1143 for problems this causes.

Using non-default credentials caches / cache collections with commands that want to search them causes the default credentials cache collections to be searched instead, and worse, credentials possible to be created there.

The cache collection APIs we copied from MIT Kerberos all lack a suitable way to identify a collection, and all instead search all the default collections:

• krb5_cc_cache_match() -- no cache [collection] name in sight in its prototype
• krb5_cccol_cursor_new() / krb5_cccol_cursor_next() -- no cache [collection] name in sight in its prototype

On the other hand, krb5_cc_cache_get_first() does have a const char *type argument that we can change to const char *type_or_collection (i.e., allow it to accept SCC but also SCC:${HOME}/.scc, for example), but then the get_cache_first() method of krb5_cc_ops doesn't itself take a similar argument, thus we cannot extend ``krb5_cc_cache_get_first()'s semantics in this way without adding a new method to krb5_cc_ops` that is like `get_cache_first()` but which takes that same extra `const char *` argument.

Things we could do about this:

• nothing, except maybe document the problem and how to avoid it by avoiding command options that lead to the use of these APIs, or by using command options that cause these APIs to not be used
• add per-cache type environment variables by which to change the default collection for each cache type (like KRB5CCNAME, but x6)
• add new versions of all these APIs that take an optional string argument naming either a cache collection to search or a type whose default collection to search

We should probably also ask @greghudson what MIT Kerberos might or might not accept in this space. We can diverge, naturally, but if we can at least get consensus on whether one ought to even be able to have non-default cache collections, that'd be great.