Recreated service shall connect with existing ports

[elfenpiff]

Brief feature description

When a service object (PortFactory) goes out of scope, the service can no longer be found, but all existing ports are able to continue communication. When now the same service is created again, it fails since old ports and the dynamic service info is still existing.

Two approaches are possible.

1. Remove the dynamic service info and create new ports that no longer are connected to the old existing ports - may surprise the user.
2. Verify that the dynamic service info belongs to a former service with the identical configuration, and reuse it again. Would allow the newly created service to create ports that can communicate with the existing ones.

Detailed information

To verify that the service has the identical static service configuration, we need to hash the object and compare the hashes. If they are equal, the dynamic service info can be reused.
This also means that the hash must be stored in the dynamic service info.

[elBoberido]

Philosophical question, when is a service the same. Let's assume there is a semantic update and the f64 does now mean m/s instead of km/s or the distance is now in m instead of km. It's an edge case and might be solved by adding semantic context to the data types.

[elfenpiff]

@elBoberido A service is the same when the hash of the static service information is equal. This is the case when the message type is equal. When now a service has the same message type does interpret the data differently, you have a problem.
But somehow it feels that this problem is not just restricted to recreating services, but also when a publisher or subscriber in the middle misinterpret the data - like the Mars Climate Orbiter. This is for me a bug in the code that can be fixed by using strong types.