Fix ksu crash in cases where it obtains the TGT

In order to allow ksu to use any locally-present service key for
verifying creds, the previous change to ksu switched from using a
retrieved or obtained TGT to fetch creds for the local "host" service,
and then passing those creds to krb5_verify_init_creds(), to passing the
retrieved TGT directly to krb5_verify_init_creds().

It did not take care to retrieve the TGT from the temporary ccache if it
had obtained them, and in those cases it would attempt to verify NULL
creds.

Modify the krb5_get_tkt_via_passwd() function to call
krb5_get_init_creds_password(), to pass back the freshly-obtained creds,
to take a "krb5_get_init_creds_opt" pointer instead of a locally-defined
options structure, and rename it to ksu_get_tgt_via_passwd().

ticket: 8015 (new)
target_version: 1.13
tags: pullup
Restore providing password TGTs for the ksu target

The use of "stored" was originally for marking whether or not creds
had been found in the source cache and copied to the target. If it was
false, the obtain-a-TGT-using-a-password path would be triggered and
it would populate the target ccache directly.

When the intermediate cache was introduced (in commit dccc80a), the
variable started marking whether or not creds had been copied to the
intermediate cache, and this was then used to decide whether or not to
copy creds to the target cache.

The obtain-a-TGT-using-a-password path began storing its creds in the
temporary cache as well, but neglected to set the flag so that the
creds would be copied to the target cache later, so the target ccache
would never be created and populated with the newly-obtained TGT.

ticket: 8016 (new)
target_version: 1.13
tags: pullup
Work around replay cache creation race

If two processes try to initialize the same replay cache at the same
time, krb5_rc_io_creat can race between unlink and open, leading to a
KRB5_RC_IO_PERM error.  When this happens, make the losing process
retry so that it can continue.

This does not solve the replay cache creation race, nor is that the
only replay cache race issue.  It simply prevents the race from
causing a spurious failure.

ticket: 3498
target_version: 1.13
tags: pullup