Revisit zenoh_router_check

[clalancette]

During rmw_init, we end up making a call to see if the Zenoh router is available:

rmw_zenoh/rmw_zenoh_cpp/src/detail/zenoh_router_check.cpp

Lines 51 to 81 in ae14222

	rmw_ret_t zenoh_router_check(z_session_t session)
	{
	// Initialize context for callback
	int context = 0;
	// Define callback
	auto callback = [](const struct z_id_t * id, void * ctx) {
	const std::string id_str = zid_to_str(*id);
	// Note: Callback is guaranteed to never be called
	// concurrently according to z_info_routers_zid docstring
	(*(static_cast<int *>(ctx)))++;
	};
	rmw_ret_t ret = RMW_RET_OK;
	z_owned_closure_zid_t router_callback = z_closure(callback, nullptr /* drop */, &context);
	if (z_info_routers_zid(session, z_move(router_callback))) {
	RCUTILS_LOG_ERROR_NAMED(
	"ZenohRouterCheck",
	"Failed to evaluate if Zenoh routers are connected to the session");
	ret = RMW_RET_ERROR;
	} else {
	if (context == 0) {
	RCUTILS_LOG_ERROR_NAMED(
	"ZenohRouterCheck",
	"No Zenoh router connected to the session");
	ret = RMW_RET_ERROR;
	}
	}
	return ret;
	}

.

However, in a very busy system that check might timeout, even though it would (eventually) find the router.

There are several ways we could handle this:

1. Increase the timeout for z_info_routers_zid. This has the problems of a) not knowing how to do that, and b) choosing a timeout value that is short enough not to hang if the router isn't available, but long enough to deal with busy systems.
2. Wait forever for a router to appear. This is very ROS 1-like behavior.
3. Do router detection asynchronously. During initialization we would query for the router, but we wouldn't wait around for a response. Assuming that the router "eventually" responded, we would have a callback that marked that fact. If the router didn't respond in some timeout (this could be many seconds), then we would print a warning message to the user.

There may be additional ways to deal with this.

[fujitatomoya]

@Yadunund /assign

[Yadunund]

Closed by #135