Add timeout fundamentals for daemon client communication

[cottsay]

This PR is more of a proof-of-concept than a concrete proposal.

If there is a broken ROS 2 daemon process or another completely unrelated TCP server listening on the corresponding XMLRPC port, it's possible for calls like is_daemon_running to hang for a VERY long time.

For example:

• In one shell, start a simple TCP server on port 11511: nc -k -l 11511
• In another shell, run ros2 daemon status

You can see the XMLRPC request on the server, but without a response, the call to ros2 daemon status will just sit there. I'm not sure how long it will go before the "global default" timeout will kick in, but I haven't waited long enough to see it.

This can be a particularly bad problem in this package's tests, many of which connect to and sometimes create and destroy daemon processes. It would be nice if those tests didn't hang.

Possible mitigation for problems like #610 and #737

[fujitatomoya]

having HTTPConnection.timeout set looks reasonable to me.

[fujitatomoya]

using global default timeout would never time out with my environment... trying to access the server to list the method in localhost, it is not expected to take more than 10 seconds, maybe we can set specific timeout in default here?

[cottsay]

I can't think of any reasonable circumstances where it would take longer than that either. I'm in favor of a default timeout as well, but I think we need more feedback on what value might be appropriate.

I also think we need to improve the error message if it becomes the default behavior. Right now, the exception is unhandled.