[mdns]: Fixed some minor bugs

[david-cermak]

Github issues

• 9270a1a fix(mdns): Move MDNS_NAME_BUF_LEN to public headers
• 77532f9 fix(mdns): Cleanup includes in mdns.c
• 5eddc9c fix(mdns): Allow advertizing service with port==0
• 980f3d3 fix(mdns): Fixed complier warning if MDNS_MAX_SERVICES==0

Coverity issues

• a69123d fix(mdns): Fixed potential out-of-bound interface error
• 80a7b1f fix(mdns): Fixed incorrect error conversion
• 411dee4 fix(mdns): Fixed potential overflow when allocating txt data

[zwx1995esp]

Hi, @david-cermak Another topic: I noticed that mDNS creates a non-recursive mutex and this kind of mutex can only be taken once by one task refer to FreeRTOS:

As far as I know, the APIs with the prefix _mdns_xxx are implemented without acquiring and releasing the lock, this kind of APIs is private and only used by mdns task internally. And the APIs mdns_xxx are implemented with the lock acquired and released, this kind of APIs is public and can be accessed by the users(but only the user? Could mdns task call these APIs?). So, currently we can not call any mdns_xxx in mdns task. Is this designed deliberately? If we use a non-recursive mutex, then in mdns task, we can call both mdns_xxx and _mdns_xxx APIs.

[david-cermak]

Hi, @david-cermak Another topic: I noticed that mDNS creates a non-recursive mutex and this kind of mutex can only be taken once by one task refer to....

Valid point, but won't address this in this PR. I'm going to work more on mdns in the near future though, so I'll reconsider.
the general idea is use non-recursive mutex, unless necessary, which up to this point was not, but that may change in the future.

[david-cermak]

Thanks for the review @euripedesrocha and @zwx1995esp , I'll go ahead and merge this as is as I think I've addressed all the comments. I'll continue in #732 which depends on this one