Hue: Fix multi-component device initialization race condition

[dljsjr]

Type of Change

• WWST Certification Request
  • If this is your first time contributing code:
    • I have reviewed the README.md file
    • I have reviewed the CODE_OF_CONDUCT.md file
    • I have signed the CLA
  • I plan on entering a WWST Certification Request or have entered a request through the WWST Certification console at developer.smartthings.com
• Bug fix
• New feature
• Refactor

Checklist

• I have performed a self-review of my code
• I have commented my code in hard-to-understand areas
• I have verified my changes by testing with a device or have communicated a plan for testing
• I am adding new behavior, such as adding a sub-driver, and have added and run new unit tests to cover the new behavior

Description of Change

We've identified an issue in the Hue driver related to the way we handled device init on driver startup for child devices that were ahead of the parent bridge in database order.

The race condition primarily manifested in the non-primary component for multi-component devices (such as multi-button remotes) not emitting attribute events or being able to handle capability commands.

The actual bugfix change is here: e4cc7a4

The other two commits are chore work that we tackled in the process of fixing the bug:

• Mostly updates type hints/annotations
• Fix one place where typechecks caught a missing nil checkCheck all that apply
• Updates to the cheekily named "logjam" module that this driver uses to wrangle its extensive/complicated logging.

Fixes #1674

Summary of Completed Tests

Tested with various multi-button remotes.

[github-actions]

Channel deleted.

[github-actions]

Test Results

   64 files    402 suites   0s ⏱️
2 002 tests 2 002 ✅ 0 💤 0 ❌
3 456 runs  3 456 ✅ 0 💤 0 ❌

Results for commit 6b62177.

♻️ This comment has been updated with latest results.

[github-actions]

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against 6b62177

[FreeMasen]

I really like the logjam stuff. I wonder if we could get this into the lua_libs as it seems like it would be universally useful drivers.

[FreeMasen]

nit: what is this indicating, that the function could return any number of additional any typed arguments? What is the advantage of adding this instead of enumerating the actual return types after the two know error values?

[dljsjr]

This was to make the typechecker happy. The actual unpack here should stop at the three things indicated, but the signature of table.unpack in LuaLS's meta typedefs indicates up to 12 return values.

[dljsjr]

I really like the logjam stuff. I wonder if we could get this into the lua_libs as it seems like it would be universally useful drivers.

I had the same thought. There are a few more refinements I want to make, but I was thinking it would make sense to port this over to the main log API eventually.