Reduction of broadcast traffic

[cdjackson]

During some recent testing with a reasonably large network, it has become obvious that the framework is sending too many broadcasts - especially on startup. On the Ember NCP this causes a lot of failures - while the framework paces the number of broadcasts being sent, it does not have visibility of all other broadcasts being sent by the coordinator itself - eg APS broadcasts, APS multicasts, route discoveries, ZDO announcements or broadcast requests, PAN ID / channel / NWK key update notifications. The ZigBee (or 802.15.4) spec limits the number of broadcasts that can be sent to around 8 in an 8 second period - the transaction manager respects this (currently only releasing a broadcast every 1.2 seconds) but if there are other broadcasts going on, as there will be when the network is starting and routes are being discovered, then many of these will fail.

So, looking at ways to reduce this...

Currently, the system always attempts to get the network address of a device by sending a broadcast on startup - the assumption being that it might have changed. However, routers should not change address, and ZEDs may change address if they change parent, but that does not happen often. Therefore, it is propose to always start this discovery with a unicast, and only use broadcast as a last resort.

The ZigBeeNetworkDiscoverer also uses broadcasts for a similar reason - this was actually written before the transaction manager was implemented, and was not updated. The transaction manager performs retries of frames that time out, so the retires in this class should be removed.

[cdjackson]

Closed by #1099