Stubborn HASS MQTT Discovery

[mcspr]

AsyncMqttClient::publish method returns packet id > 0 when it is actually accepted by the network layer. worked for me with both QoS 0 (PID 1 is success) and QoS 1.
limited testing with lwip2/536mss+git, lwip2/1460mss+git and lwip1.4+2.3.0
pubsubclient works the same way, returning bool right from the .publish method.

Modified mqttSend... variants to check PID validity and check what they return in the discovery sender. Both ha relays and sensors methods modified into a helper class to store last sent internal array ID.

Additionally, this approach should also be applied to the config generator.

Depends on #1374 // F() could be removed for it to work without it
Fixes #1346
cc @peterhoeg

[peterhoeg]

Should this be tested against dev or can I cherry-pick the commits on top of the latest release?

[mcspr]

Idk if it is worth managing cherry picks, but it should work for master branch too.
homeassistant.ino had no changes since. There is one eeprom related method change in mqtt module, but it could be ignored and old one used instead.

[abmantis]

Any reason why this is still pending?

[mcspr]

IMO there should be generic callback helper in the core to avoid juggling discovery helper object. i.e. something that will call some function and allow some local state (like here - relay and sensor index sent so far), enforce uniqueness and allow it to be automatically removed when it is done.

Otherwise, I remember this being pretty robust. Maybe one thing that should be tested is DEBUG_SUPPORT=0, because of implicit yields