Add DLC/ALS authentication support for shared Hue lights

[MR-kartoshki]

Summary

This PR adds support for newer Philips Hue lights that use DLC/ALS authentication when shared through the Hue app.

Changes

• Parse hue://dlc?... sharing credentials
• Add Zigbee Direct authentication
• Establish ALS sessions using X25519 and HMAC confirmation
• Encrypt and decrypt protected GATT traffic with AES-CCM
• Re-authenticate automatically after reconnecting
• Keep legacy Bluetooth pairing behavior unchanged when no DLC credential is supplied
• Read supported colour-temperature limits from the light when available
• Add tests for DLC parsing, authentication helpers, encrypted GATT handling and colour-temperature range parsing
• Document shared-light usage and the additional cryptography dependency

Usage

light = HueBLE.HueBleLight(
    device,
    dlc_uri="hue://dlc?...",
)

HueBLE will establish the authenticated session automatically when connecting.

Warning

The DLC URI contains authentication material. Keep it private and do not commit it to source control.

Notes

The transition and expanded effect changes have been moved into a separate PR so this one is focused only on DLC/ALS support.

[MR-kartoshki]

by hue://dlc credentials I mean the credentials in the hue://dlc... link contained in the QR code

[flip-dots]

Woah this is awesome, I was really hoping someone would figure this out. I don't have enough time this weekend to properly review this (maybe next weekend) but I have skimmed it and I have a few thoughts. I think the new effects / transition support should be in a separate PR (since that should be more or less be good to go) and it might finally be the time to abandon the single file structure, it was already a bit of a mess but I think this might make it finally worth splitting things out into a proper multi file library, though how that should be laid out I am undecided on, the easiest approach might be a new class/file which extends HueBleLight and implements this new authentication or maybe some more fundamental changes should be done (like splitting out exceptions, enums, helpers, and classes), though I am not too fussed if that reorganisation is done later.

[MR-kartoshki]

I think the new effects / transition support should be in a separate PR (since that should be more or less be good to go)

done #16

and it might finally be the time to abandon the single file structure, it was already a bit of a mess but I think this might make it finally worth splitting things out into a proper multi file library, though how that should be laid out I am undecided on

Yeah I agree, and for the longer term I think it might be worth structuring it around one public HueBleLight class and moving the implementation details into separate modules rather than making a separate light subclass for each authentication method.

Something along the lines of:

hueble/
├── __init__.py
├── light.py
├── constants.py
├── enums.py
├── exceptions.py
├── effects.py
├── auth/
│   ├── legacy.py
│   └── dlc.py
└── protocol/
    ├── als.py
    └── tlv.py

HueBleLight could stay as the main public API while the authentication method, encryption, TLV handling, etc. are delegated internally. This would also make it much easier to add more features later.

I’d probably keep that refactor separate from the DLC PR though.