Ignore color_temperature attribute when computing light capabilities

[puddly]

See home-assistant/core#156133.

The device switches modes. Color temperature is the only mode where we peek at attribute values to determine capabilities (all others just use the color_capabilities bitmap). The number of affected devices according to diagnostics is very small and all of the changes look reasonable to me.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.02%. Comparing base (54975cb) to head (945cf34).
⚠️ Report is 27 commits behind head on dev.

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #572   +/-   ##
=======================================
  Coverage   97.02%   97.02%           
=======================================
  Files          63       63           
  Lines       10535    10535           
=======================================
  Hits        10222    10222           
  Misses        313      313           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TheJulianJES]

For the original GLEDOPTO GL-C-009P issue, there's an old quirk that just removes the color cluster. If that were changed to a v2 quirk, it would also fix the issue.

But I agree this is the more proper fix. Going through the affected devices, the only devices we may wanna have a look at are:

• LEDVANCE RGB light, as it seems to support color temperature in Z2M:
  zigbee-herdsman-converters/src/devices/sylvania.ts#L155-L159
  (no idea why the range is "undefined", but this seems to apply to other "tunable white" devices as well: zigbee-herdsman-converters/src/devices/ledvance.ts#L21-L25)
• the Tuya light _TZ3210_bfwvfyx1, but it apparently has lackluster support in ZHA, yet at least allows controlling the color temperature range somehow

There may be other we are missing, but I think this change should be fine (for the next major release). Only "important issue" may be this (and other?) LEDVANCE lights..

[GTerplan]

Is there any testing that needs to be done with this change? If so I am willing to apply any file changes for the issue I reported until it's put into a future release.

[puddly]

@GTerplan Give it a try, it should resolve your issue. We've identified that making this change will cause other devices to break so we're working on fixing those first.

[MattWestb]

light.ikea_of_sweden_tradfri_bulb_gu10_ws_345lm and
light.dresden_elektronik_conbee_ii_no_name_group_0x549a is doing the same after adding the new IKEA Bilresa that is likely the reason the remote setting up the group and then sending X-Y commands like IKEA always have doing / using X-Y for color management.

[GTerplan]

@GTerplan Give it a try, it should resolve your issue. We've identified that making this change will cause other devices to break so we're working on fixing those first.

@puddly Since I am using the HA OS VM I wasn't able to apply any of your changes, but I did create a zha_quirks folder within the config folder and had to modify the glc009p.py file based on my device signature. I have included the updated file here since I am hoping that can just be updated in the main zha quirks folder during an update which should not break anything.
glc009p.py