November fixes

[gbrooker]

This pull request combines a number of fixes and minor enhancements.
Fixes:

• Fix race condition when calling Evergreen logger from Server queue
• Fix for HomePod (add boolean type to possible Characteristic values). HomePod sends true or false for the "on" characteristic, whereas iPhones send 1 or 0.
• Fix for accessory configuration on restart. Prior to this fix, restarting a bridge incremented the configuration count each time, causing HomeKit to forget room settings.
• Fix for a race condition on the continueRunning flag in Server, and improve support to stop and restart the Server.

Enhancements:

• Add didChangeAccessoryList to DeviceDelegate. Allow a container app to observe changes to accessories (for dynamic accessory discovery)
• Add Device.unpairFromAllControllers(). Removes all pairings

[gbrooker]

Note the build check fails because travis can't find your new sonar-scanner checking tool.

I have looked at running sonar-scanner myself, but it seems that for swift support, one needs a paid Developer version of the SonarQube product. Is this really necessary for the GitHub pull request ?

[Bouke]

So SonarCloud doesn't (yet) support external PRs, so I'll mark SonarCloud optional (PR #60).

I see you've included the changes from your previous PR (#55), which I'm not yet sold on. In order to get this PR ready for merge, exclude those changes.

The OpenWeather looks like a nice example of how to implement a software-only sensor. I'd rather not include it with the core HAP package. You could setup a separate add-on package, which we could reference from the README.

The changes regarding the race conditions / locking can be resolved by calling that code from the main thread. The main server isn't thread-safe and should always be controlled from the same thread. Making it fully thread-safe is a lot more work than just asserting the code is called from the "correct" thread. That'll resolve programming errors and will be a lot safer. What do you think?

[gbrooker]

So SonarCloud doesn't (yet) support external PRs, so I'll mark SonarCloud optional (PR #60).

Great, thanks, I'll rebase the two PR's

I see you've included the changes from your previous PR (#55), which I'm not yet sold on. In order to get this PR ready for merge, exclude those changes.

Not sure how you got that impression. I already backed out everything from the other PR

The OpenWeather looks like a nice example of how to implement a software-only sensor. I'd rather not include it with the core HAP package. You could setup a separate add-on package, which we could reference from the README.

I'll respond to this in PR #55

The changes regarding the race conditions / locking can be resolved by calling that code from the main thread. The main server isn't thread-safe and should always be controlled from the same thread. Making it fully thread-safe is a lot more work than just asserting the code is called from the "correct" thread. That'll resolve programming errors and will be a lot safer. What do you think?

The changes regarding race conditions are to fix an issue in the current codebase, no matter if the code is called by the main thread or not. The dispatchPrecondition is not a 'solution' but an aid to a developer to ensure there is not a threading error while testing their application.

I'll do some exercises in git to split out each of the changes here into separate PR's, so we can discuss each one individually.

[gbrooker]

This PR has been split into PR #61 (Fix for HomePod) , PR #62 (Fix initial accessory configuration), PR #63 (Fix unpairing) and PR #64 (Fix Server race conditions), and so will now be closed.