[krbdev.mit.edu #3334] libkrb5 treats all KDC errors as terminal

[Ken Raeburn via RT]

Overall, I think this is the right approach to use.  I'd suggest a  
few minor(?) changes, and have some notes:

* Make the error message a little more meaningful to the user.   
Frankly, I think it's kind of silly to be telling the end user about  
specific internal errors in the KDC, but here we are...

* The sendto and sendto_kdc interfaces are private; we can just  
change them, and the callers.  It probably means a bigger patch, but  
less proliferation of internal interfaces.  (And for simplicity,  
perhaps a null callback function pointer should mean to return on  
receipt of any complete message.)

* After working with a few callback interfaces, I think it's a good  
idea to avoid mingling "abandon this connection" flags and OS errors  
or errors reported by the other party in a callback interface.  The  
controlling loop is simpler if the callback can only tell it "keep  
going" vs "abandon this connection" vs "we're done", and any error  
indications needed but irrelevant to the controlling loop itself can  
be stuffed in the callback data structure, to be checked by the  
caller when the controlling loop returns.  This is especially true if  
you can get errors that you might want to report depending on the  
results of other calls, so your control loop would potentially have  
to track multiple error conditions.

* Rename the typedef krb5_select_kdc_fct so it doesn't refer to KDCs  
specifically in the sendto interface, which isn't specific to KDC  
exchanges.  Maybe something like sendto_response_handler, and maybe  
make the function pointer plus data pointer into a struct like was  
done with struct sendto_callback_info (which perhaps now should be  
renamed since it's not the only callback) for constructing per-server  
messages.

* Someday, we could make sendto_kdc return the error structure we've  
already parsed (to see if it was SVC_UNAVAILABLE).  Currently,  
sendto_kdc just passes back a krb5_data.  Just noting this for the  
future...

* We could also check for RESPONSE_TOO_BIG, and shut down only the  
one UDP socket.  Our current behavior is to quit out of the whole  
sendto loop when we get the response, and shut down all the UDP and  
TCP sockets; then we analyze the returned message, see that it's  
RESPONSE_TOO_BIG, look up the TCP KDC service again, and start up the  
TCP connections again.  That's pretty wasteful.  Keeping the other  
UDP sockets open (and, in fact, possibly opening new UDP sockets)  
until we get back RESPONSE_TOO_BIG on them is also wasteful, but  
perhaps not quite as bad.

Ken