[mdns-avahi] handling of group state callback

[abtink]

Documenting this issue I noticed as reading the Avahi APIs and our code so to remember and can fix it later.

• When we create a AvahiEntryGroup we pass it a callback function so it can report status of service/record registration to us.
• The Avahi documentation mention the following:

This callback is called whenever the state of this entry group changes. May not
be NULL. Please note that this function is called for the first time from
within the avahi_entry_group_new() context! Thus, in the callback you should
not make use of global variables that are initialized only after your call to
avahi_entry_group_new(). A common mistake is to store the AvahiEntryGroup
pointer returned by avahi_entry_group_new() in a global variable and assume
that this global variable already contains the valid pointer when the callback
is called for the first time. A work-around for this is to always use the
AvahiEntryGroup pointer passed to the callback function instead of the global
pointer. 

• Other avahi APIs that control/update an AvahiEntryGroup (like avahi_entry_group_commit()) may also invoke the callback before returning. We need to be ready to handle these cases.

In our PublisherAvahi::PublishServiceImpl() we create an Avahi group, use Avahi APIs to add text data, sub-type, and service info and then commit the group. Only after all the above steps, we allocate and add a corresponding AvahiServiceRegistration to list of registrations (which saves the created AvahiEntryGroup *).

The callback we set when we create an Avahi group is our PublisherAvahi::HandleGroupState() method. In this method we try to match the input aGroup pointer with entries in our service registration list. If the callback is called before we reach end of PublishServiceImpl() method, the list will not have the corresponding entry so there is possibility that we miss a callback from Avahi. I think/hope this situation is not likely (though technically valid and possible, specially in case of failures) and we should try to properly handle this in our Publisher implementation.