Sometimes Avahi continues to defend srp entries that OTBR no longer has context on

[ndyck14]

We've observed some cases where Avahi will continue to defend SRP entries that are no longer valid. This can result in a number of problems with varying severity:

1. Multiple ip addresses may be advertised even if they are no longer in use due to changing OMRs
2. In multiple BR environments, later re-registration on one active BR may be blocked by the other due to hostname conflict (when SRPL not enabled)
3. In multiple BR environments, later re-registration may be permanently blocked if affected BR is no longer active SRP server due to max entries (2) restriction (when SRPL not enabled)

Reproduction steps are currently unknown

1. Git commit id (checking, but fairly recent)
2. IEEE 802.15.4 hardware platform (silabs RCP)
3. Build steps
4. Network topology (observed on a variety of networks)

discussing with @abtink: The way Avahi APIs work is when we call its API to register a service it gives us back an AvahiEntryGroup * pointer. While this AvahiEntryGroup * is not freed the service is advertised, when this is freed, the service is removed (not advertised).

It seems to me, one hypothesis is that this bug has cases that cause OTBR to lose context on this pointer without properly freeing it. One mitigation step we could consider if full reproduction steps are not found is to modify these pointers to have a lifetime that mirrors the SRP lease time. That way, at least this issue becomes more transient instead of permanent (until BR restart).

cc @jwhui @gabekassel