More robust gateway flip shutdown/connection error handling

[asmodehn]

[rocon_gateway] deleting old flips when flipping again, in case. [rocon_gateway] not unregistering gateway on shutdown to have similar behavior if error [rocon_hub] simplify gateway unavailable/dead to have only one state "gone" [rocon_hub_client] small fix to trigger update and exit quickly on shutdown

adding exception handler for registering/unregistering services/topics fixing launcher to have only one timeout for gateway "gone" cosmetics

removing external_shutdown special case. simpler shutdown behavior.

improving unavailable -> gone transition. not trying to talk over network when gateway disappear (connection might be down).

now gateway always check its hubs for valid data and can refresh it if needed.

HubConnectionFailedError exception fix.

generous timeout to find connection_cache

fixed behavior when hub disappear. cosmetics.

[stonier]

This is a squash of pull request #339. More history there.

[stonier]

Goes with https://github.com/robotics-in-concert/rocon_concert/pull/318

[asmodehn]

How to test:

Simulation on one host (simple - mostly valid if no special shutdown code) :

1.a. Concert stop

• Start Robot and Concert
• Kill Concert (via killing roslaunch) => Notice gateway disconnects
• Optionally : wait a bit longer (60 secs : timeout will kick in and remove gateway data)
• Start Concert => Notice gateway connection is reestablished

1.b. Robot stop

• Start Robot and Concert
• Kill Robot (via killing roslaunch) => Notice gateway disconnects
• Optionally : wait a bit longer (60 secs : timeout will kick in and remove gateway data)
• Start Robot => Notice gateway connection is reestablished

Simulation on multiple hosts (VM or Hardware - more tricky, but more valid than 1.) :

2.a Network outage

• Start Robot and Concert
• Trigger network disconnection (go out of wifi range, break VM network connection) => Notice gateway disconnects
• Optionally : wait a bit longer (60 secs : timeout will kick in and remove gateway data)
• Reconnect network

=> Notice gateway connection is reestablished via :

• log message
• doing a rostopic echo /concert/clients/heartbeat/beat from concert should display robots name
• doing a rostopic echo /concert/clients/heartbeat/echo from robot should display robot name Note : if multiple robots, beat topic on concert and echo topic on robot will show all robots names.

Multiple robots Repeat 1.b and 2.a for each robot.

• Notice that robots gateway do not influence each other
• Notice that beat topic on a robot, only contain that robot name, but beat topic on concert and echo topic on robot will show all robots names.

More : find all kind of funny ways to break and reestablish network connection (as verified by ping). Gateway connection should always be reestablished automatically, even if it s only for a short time.

[stonier]

Ran simple bringup/crash robot tests, go out of range for variable length of time and then back in tests.

These all worked fine. Extreme testing will be the elevator, @asmodehn says he has done some there and these worked ok, but let's keep an eye on it there as that is where it can get inside the loop rates and possibly break things.