[FEAT]: Topological Map UUID

[Iranaphor]

Description

In the usage of a topological map launched on a remote server, facilitating multiple robots and a coordination server, it seems necessary for it to be launched with a UUID, and for this same UUID to be sent along with any gotonode and executepolicymode messages.

The usage aim is that if the topological map is updated and republished on the remote map server, every agent which has a map already loaded should update live. With this, it is important that there is a method to address syncronicity in the control messages utilising the map. Without it, there could be problems of mismatch between node/edge names resulting in collision.

To address this, I recommend 3 changes:

1. a UUID and header be applied to the map data when loaded by the map server, when a new map is loaded it is published with a new UUID and an updated timestamp
2. when a new map is recieved by navigation2.py and localisation2.py, they check if the timestamp is newer before updating the locally stored map
3. a UUID field is added to the gotonode and executepolicymode message formats so when a route is recieved, if it is not for the currently loaded map, it will be ignored

Additional Information

No response

[marc-hanheide]

I see your point. We basically need versioning of maps. A UUID seems an appropriate mechanism to achieve that. An alternative could be checksum/hash calculated over the map, as is the standard e.g. for certificates to verify their authenticity (i.e. that they match the expectations). That would only need changing the actions, as they will include the authenticity hash, and actions that don't match the current map would be rejected. It would avoid a UUID, but in the end I don't care too much. Who'll implement?