[krbdev.mit.edu #8764] get_creds can add redundant cache entry for referral ticket

[Greg Hudson via RT]

This is a minor bug.  To reproduce it, change t_referral.py, adding a 
line "realm.run(['./gcred', 'srv-hst', 'a/x.d at REFREALM'])" just after 
the shutil.copyfile() invocation in testref.  The following three 
entries will appear in the klist output before the script fails:

12/12/18 11:28:52  12/13/18 11:28:52  a/x.d at REFREALM
12/12/18 11:28:52  12/13/18 11:28:52  a/x.d@
12/12/18 11:28:52  12/13/18 11:28:52  a/x.d at REFREALM

The first entry was added when we explicitly looked up 
a/x.d at REFREALM; the second was added when we asked KRBTEST1.COM for 
a/x.d, got a referral, and followed the referral to get a ticket for 
a/x.d at REFREALM.  We store that ticket as a/x.d@ (the server principal 
asked for by the caller; krb5_cc_store_cred() then stores it again 
with the ticket server.

We could:

1. Ignore this problem.  It probably doesn't happen very often and 
the consequences aren't severe.  (The cache doesn't grow without 
bound or anything, like it did in #8579.)

2. Make get_creds check the cache for a/x at REFREALM before following 
the referral TGT.  If we find it, we still need to store as a/x@, but 
not as a/x at REFREALM again.  (Currently this is impossible because 
krb5_cc_store_cred() performs the double store without being asked; 
that logic would have to be pushed upwards.)

3. Make krb5_cc_store_cred() check if there is already a cred for the 
ticket server in the cache before doing the second store.

4. Just get rid of the second store operation in krb5_cc_store(), 
following the logic of #8579 that there isn't much value in storing 
cache entries for things the caller didn't ask for.  If we do this, 
we might also want to modify klist to display the ticket server if it 
differs from the credential entry server; otherwise there is no way 
to see in the klist output what the server realm is for a cacched 
referral result.