Services: Improved behavior when the first route to the server doesn't work

[FlorianReimold]

Description

Before, the Service Client would only try the very first route to the Service Server. Now, it will go through all routes until it finds one that works.

Cherry-pick to

• none

[github-actions]

clang-tidy made some suggestions

[KerstinKeller]

On GH Actions, some Unit Tests are now failing:

4: [  PASSED  ] 10 tests.
4: [  FAILED  ] 1 test, listed below:
4: [  FAILED  ] ClientServer.ClientConnectEvent
4: 
4:  1 FAILED TEST
 4/14 Test  #4: test_clientserver ................***Failed   72.27 sec

It also fails locally on my machine @FlorianReimold

[KerstinKeller]

Generally, I approve, however, I do have one question.
The test increase the timeout to 20seconds. In real life, how long does the host name resolution take and is it done synchronously or asynchonously?

[FlorianReimold]

Technically speaking, the hostname resolution is async:

ecal/ecal/service/ecal_service/src/client_session_impl_v1.cpp

Line 85 in c0116ac

resolver_.async_resolve(query

I don't know how long the hostname resolution takes. I think it is "fast".

But obviously, you need to wait for the hostname resolution and the connection establishement to finish, before the service can return any response.

The reason for the high timeout is, that eCAL doesn't use the immediate callbacks from the service library

How it should be:

• eCAL detects service server via registration layer
• Service client resolves hostname
• Service client connects to service server
• ...
• Service server is deleted
• Service client immediately fires disconnection callback which is forwarded to the user

How I think it is implemented:

• eCAL detects service server via registration layer
• Service client resolves hostname
• Service client connects to service server
• ...
• Service server is deleted
• Service client fires disconnection callback, but this is not used
• ...
• eCAL runs registration layer and detects that the server is gone
• eCAL tries to reconnect the client to the server anyways (I didn't debug it, only looked at the logs. But for some reason this seems to happen)
• Service client resolves the hostname
• Service client connects to non existing service server (fails)
• eCAL fires a custom disconnection callback