[AFS3-std] Standardization of GetCapabilties RPCs for AFS3 client and services

[Ken Hornstein]

>Also, this is not an application-level capability of the server; it's an 
>rx-level capability.  I believe we determined in discussions at the last 
>hackathon that if an application wishes to use TCP, the cost of trying it 
>first and falling back to UDP is relatively low.

I remember that discussion ... but that pesky real world keeps getting
in the way.

Here are some issues:

- Implementing the automatic fallback at the RX layer is ... well,
  complicated.  It just makes the code even more of a mess than it is
  now, and presents a number of other problems.  Like ... should we be
  doing a blocking connect() and wait for the complete TCP timeout?
  Should we do something shorter?  If we want to completely rewrite RX
  so multiple transports can be done more cleanly, then of course life
  is simpler ...  but I don't see anyone stepping up to do that work,
  and _I_ am certainly not volunteering.

- If we get ECONNREFUSED, should we try UDP, or return an error message
  back to the application?  I can think of difference cases where each one
  of those responses are the "right" answer.  What happens if we get a timeout?
  Should we revert to UDP always?  Some of the time?  Never?

- Like you said, the "right" answer probably depends somewhat on network
  connectivity.  Should we depend on client configuration for this?  Should
  server Rx capability be cached by the client?

Clearly balancing the theoretical ideal versus what it's feasible to
implement needs some work.  I'm sure I don't have all of the answers,
I'm just talking out loud.  If anyone has any other thoughts, I'd be
glad to hear them.

--Ken