Client subscribing to events can be blind for up to 200 seconds if the target device is restarted (device restart)

[bourtemb]

A client subscribing to events on an attribute does not receive events during a period of time which can be as long as 200 seconds in case the target device is restarted (device restart, not process restart).
No error is reported on the client side so a GUI will continue to display the old attribute value, which might be wrong.
The client will start receiving again events after the device restart when it will send an event resubscription command. These event resubscription commands are sent by every client every 200 seconds.
If there are several clients subscribing to the same event, as soon as one client has sent the resubscription command, the other clients will receive again the events.
This behaviour has been observed with Tango 9.2.5 (client and server side) too.

[bourtemb]

This problem seems to come from the fact that EventSupplier::detect_and_push_xxx_event() methods (there might be others) are checking the Attribute::client_lib vector to see whether there are some clients interested in some events for this attribute...
When a device is restarted, the Attribute object is deleted and recreated but the client_lib vector information is lost on the way so the device server thinks there is no client interested in receiving events for this attribute, until a client sends a resubscription command (every 200 seconds) because Attribute::client_lib is no longer empty after the resubscription.

So we need to find a way to backup this information before device deletion and to restore it after the device has been recreated.
There are already some mechanisms to store some event related information, including the client_lib information in DServer::restart() method using MultiAttribute::set_event_param() and MultiAttribute::get_event_param() methods. But this mechanism seems to rely on the fact that the attribute indexes in the device attribute lists will not change after the restart. The Attribute::client_lib is also not currently restored, even though the information is available.
In the case of a device server creating dynamic attributes based on a device property, if this property is updated, a device restart might trigger the creation of some new dynamic attributes and some previously created dynamic attributes might disappear after the restart (This could be a good reason for the user to restart the device). In this case, the attributes indexes in the device attributes list might be different after re-creating the device and this MultiAttribute::set_event_param() and MultiAttribute::get_event_param() mechanism will not work as expected.
We need to find a way to save the attribute names in get_event_param() and avoid relying on the device attributes list indexes in set_event_param() and use the attribute names instead (use get_attr_by_name instead of get_attr_by_ind in MultiAttribute::set_event_param(vector &eve) method).