Workaround for wait_for_service lasting the full timeout with connext

[dhood]

Fixes ros2/rmw_connext#280

We already have a workaround in the implementation of wait_for_service_nanoseconds to accommodate a race condition in connext between when the graph condition is triggered and when the service is reported as being available (#262).

While that workaround works, it can be slow if there are no other graph events coincidentally happening at the same time. Currently, when we are hit by that race condition, we get stuck waiting the full duration of the remaining time_to_wait before the wait set wakes up again and we notice the service is now available.

This PR changes the behaviour to put a max wait in the wait_for_graph_change so that in the event we are hit by the race condition, we recover from it in a limited amount of time (I chose 100ms arbitrarily).

I didn't find where the race condition is coming from yet. I have an idea which I'll put on ros2/rmw_connext#201

This adds overhead of graph wakeups and service_is_ready checks. We can only add that if connext is being used if we think it's worthwhile.

Standard CI:

• Linux
• Linux-aarch64
• macOS
• Windows

CI repeating test_client_scope_cpp 100 times with its timeout lowered from 60s to 10s: (used to be regularly flaky with a 30s timeout)

[wjwwood]

LGTM

This is fine, and should only incur a small performance penalty. However, as you pointed out it just better masks the original issue. But this is a good incremental improvement to deal with that race until a proper fix can be found.