Name conflict resolution when adding srp service

[ndyck14]

Do we currently support resolving name conflicts when adding services:

openthread/include/openthread/srp_client.h

Line 521 in ccf8ea6

otError otSrpClientAddService(otInstance *aInstance, otSrpClientService *aService);

It looks like we don't, at least from the API arguments. While this is not (as) important for application layers like Matter, there are other applications that would benefit from it (we've had to work around it ourselves)

There are two cases:

1. Name conflict on the current mesh (the one I am referring to here)
2. Name conflict on infrastructure (may already be handled by proxy code?)

@jwhui @abtink

[abtink]

We already have certain mechanisms which can allow name conflict resolution to be implemented by next layer:

• OT SRP client expects all the info about the service/host (names) to be given to it by next layer (sw entity that is calling its API adding/removing service and host info)
  • Since the OT SRP client is not itself selecting any of the names, it does not make sense for it to change and modify them as well. So it keeps trying to register the requested services until it is instructed otherwise (its APIs are called to remove or change).
• Instead it provides callback otSrpClientCallback which can be registered by next layer to be informed of errors including potential name conflict (YXDOMAIN is mapped to OT_ERROR_DUPLICATED).
• The next layer (matter or similar layer) can decide to take any action that make sense (e.g. clear or remove the service causing conflict, decide on a new name, then re-add service with new name).

[ndyck14]

Seems reasonable for now.