Allow participants to sync up with remote databases when discrepancies arise

[mxgrey]

There is a very small probability in the event of server restart race conditions that a participant may disagree with its remote database on details like its participant ID and description.

This PR allows participants to identify when these issues occur and work out a correction with the remote database.

We limit the rate at which these corrections can occur, because there is a risk of a pathological case where two participant instances believe they both own the same name. If that happens then they might viciously cycle against each other, each trying to "correct" the "bad" information that's being pushed by the other. In the worst case scenario that could be a very tight loop of hammering "corrective" messages at the schedule node. We limit the rate to 3 corrections per minute. Corrections happening at a higher rate than that should be brought to the attention of an operator.

To test this PR you can run four terminals with the following commands:

$  ros2 run rmf_traffic_ros2 changed_participant_schedule_node

$  ros2 run rmf_traffic_ros2 mock_repetitive_delay_participant

$ ros2 topic echo /rmf_traffic/itinerary_delay

$ ros2 topic echo /rmf_traffic/participants

Then watch as the participant makes corrections to the sabotage that the mocked up schedule node is causing. This scenario is also designed to demonstrate the rate limiting of the corrections.

This PR depends on

• Add a class to help with limiting rates of events rmf_utils#18 which can be merged first
• Allow the rectifier to help fix participant ID and description discrepancies rmf_traffic#54 which must be merged simultaneously

[aaronchongth]

This is looks amazing! Thanks for the explanation and comments along the way. I just have a few nitpicks, but in general I'm seeing the intended behavior and it should be in good shape to be merged after the base branch is updated.

[codecov]

Codecov Report

Merging #145 (fd2def0) into main (a88fd24) will decrease coverage by 0.30%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #145      +/-   ##
==========================================
- Coverage   21.52%   21.21%   -0.31%     
==========================================
  Files         422      856     +434     
  Lines       34378    69752   +35374     
  Branches    16260    32920   +16660     
==========================================
+ Hits         7401    14801    +7400     
- Misses      19043    39106   +20063     
- Partials     7934    15845    +7911     

Flag	Coverage Δ
tests	21.21% <ø> (-0.31%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
..._adapter/src/rmf_fleet_adapter/ScheduleManager.cpp
...s2/src/rmf_traffic_ros2/schedule/internal_Node.hpp
...2/rmf_fleet_adapter/test/phases/test_GoToPlace.cpp
...fleet_adapter/src/rmf_fleet_adapter/estimation.cpp
...-4.1.0/Rx/v2/src/rxcpp/schedulers/rx-eventloop.hpp
...RxCpp-4.1.0/Rx/v2/src/rxcpp/operators/rx-merge.hpp
...f_fleet_adapter/agv/internal_RobotUpdateHandle.hpp
...rc/rmf_traffic_ros2/schedule/convert_Itinerary.cpp
...er/src/rmf_fleet_adapter/agv/FleetUpdateHandle.cpp
.../rmf_fleet_adapter/src/mock_traffic_light/main.cpp
... and 1268 more

[aaronchongth]

Tests and demos are working fine, the example you provided with is working as expected too. Thanks!