[krbdev.mit.edu #6604] issues with gss_inquire_context and gss_display_context when using SPNEGO

[Greg Hudson via RT]

I discussed this issue with Nico, our resident mechglue expert.  Here
was the takeaway:

* There is no fundamental reason to unwrap the double-layered union mech
except perhaps performance (avoiding the two extra function calls for
each message operation).

* gss_inquire_sec_context should be returning the actual mechanism, so
that's a bug.  (More on the best way to fix that later; we were
interrupted by lunch.)

* gss_display_status doesn't accept a context as an argument; it accepts
a mech.  If the app is passing the correct mech to gss_display_status,
then the negotiated mech's error codes should be displayed correctly. 
So if gss_inquire_sec_context is fixed, error codes should not be a
motivation for unwrapping the double-layered union context.

* If we did want to unwrap the double layering, the way to do it would
be to require mechs to return a union context if they set *actual_mech
(for init) or *mech_type (for accept) to a value other than the initial
mech type (for init) or the token mech type (for accept).  We already do
something similar for delegated creds.