Publish fleet and task updates over ROS 2 if websocket is not provided

[aaronchongth]

New feature implementation

Implemented feature

Allows fleet_state_update, fleet_log_update, task_state_update, and task_log_update to be published over ROS 2 when websocket server URL is not provided.

Works with open-rmf/rmf-web#1003

Implementation description

The motivation is related to open-rmf/rmf-web#899, where non-reproducible issues with websockets occur unpredictably in production environments, causing various systems to fail.

This allows the option to mitigate issues with the upstream websocketpp library, and just rely on ROS 2 to publish updates instead.

This will also allow the use of ROS 2 introspection tools in production if network instability occurs, which hopefully is a much better experience than debugging websocket connections.

Testing

Instead of running demos with the server_uri, just run

ros2 run rmf_demos_gz office.launch.xml #headless:=1

[koonpeng]

Can it publish regardless if websocket is enabled?

Connection issues aside, I feel that the split of multiple transport is causing unnecessary complexities as well. websockets is the "public" api but it doesn't expose many important information (like door, lifts, maps etc), the ros2 side is "internal", does expose them but it doesn't expose task states etc. So in practice, it is very likely for downstream to have to listen to both transports and deal with 2 different message schema format.

[aaronchongth]

As per discussion, publishing over ROS 2 regardless of websocket availability makes sense