Ensure Accessory is able to be republished

[Supereg]

Ensure Accessory is able to be republished

♻️ Current situation

Currently the ability to republish (calling Accessory.publish after unpublish has been called) isn't really supported.
Further, there are regressions introduced in the past (see #895) which now prevent this completely.

💡 Proposed solution

This PR adds a minimal set of test cases to test the behavior of a publish call following a unpublish call.

Problem that is solved

With this test we identified three issues:

• The problem reported in ControllerStorage was already loaded! #895
• If addIdentifyingMaterial option was turned on, this was done a second time when republishing
• When unpublish is called instantly on the LISTENING event and the CIAO advertiser is used one might encounter a race condition where the Probing step isn't properly canceled (as the unpublish was called while the Networking stack was still initializing). This issue isn't currently fixed. As a workaround we introduced the ADVERTISED event to the Accessory class which is triggered when the advertising step completed successfully. It is noted, that this might (due to the Probing) add significant delay to the event execution when using CIAO.

Implications

➕ Additional Information

Both Accessory.unpublish and Accessory.destroy calls where modified to return a Promise now, such that one can wait until the mDNS advertising was fully removed. This only has any effects when using the CIAO advertiser.

Testing

A new test case was added to test publish and unpublish calls of an Accessory. The test case doesn't currently have extensive assertion logic (e.g. to test stuff around IdentifierCache, Accessory structure or other storage and state components). The test only expose a simple accessory (one service, no multiple service, multi controller or bridge setup).