fix: Skip attribute write restrictions for special values

[andrei-lazarov]

• fixes startUpColorTemperature requires max of 65279 zigbee2mqtt#31452
• fixes Unable to set previous in Color temp startup zigbee2mqtt#32336

• Special values take precedence over other restrictions imposed (e.g. a special value may fall outside the min/max range for the attribute).
• value is kept as string for easier handling (will be checked on spot if used anyway) though most often is a hex number string (without 0x)

@Nerivec I saw the comment above, but I think you forgot to handle this case. Is this how you intended to do it?
Still not sure why they are strings

[Nerivec]

I didn't do it because it just doesn't work in current state of things.
ZHC does too much overridding for specific devices.
Also is a mess with value type handling & typing (not everything is a number).

We'd need some kind of clearer path to implement support, making it work with ZHC is complicated as of now.

[andrei-lazarov]

That makes sense. Though in cluster.ts I only see numeric values currently.

What about ZHC conflicts with this? Can I help in that regard?
At least for the example I linked, writing works now. But I also need to allow reading

[Nerivec]

I only kept the current special values for references (pulled from the spec XML). Didn't have time yet to start the whole "next step" ZHC aspect...
It needs refactoring with proper typing and the right approach (there are at least numbers, and buffers from what I remember, might even be a few actual strings - need to re-check against the spec as well for existing & possibly missing).
Definitely need to rewrite the current strings to proper values (should have no conversion at runtime, for perf). We'll probably end up needing to type this stuff as unknown and type-cast during the processing (e.g. value === specialValue as T).
ZHC needs to pull from the spec and support both range (if number), and special values (label+value), and possibly other metadata, as appropriate, and automatically. Currently, it's all hardcoded per-definition, and there is a lack of ties between exposes and spec (everything is wrapped in custom exposes, which know nothing about backing attributes & co).
Proper integration in ZHC is a massive undertaking; since we'd implement this in a way that adds automatic support everywhere (else would defeat the point of spec-driving), we need to double check every currently hardcoded expose value for remove/keep/update, support custom clusters, etc..
If we don't refactor this cleanly, we'll just end up with another layer of hardcoded values... 😕

cf #1503

Note: processRestrictions is used for both read & write.

[Nerivec]

Gave some more thoughts to this.
I think we can refactor the special handling in two independent steps:

• ZH (should be quick enough and for now, will allow ZHC to send hardcoded special values)
  • proper type for special (i.e. probably [name: string, value: unknown][] will cast value as T on use-sites anyway, triple-equal will take care of the rest)
    • I think the Buffer ones are not really needed (if memory serves), might as well skip that extra handling
  • add handling - needs to take priority over all other checks, including non-value, so, must be done in main functions, not in processRestrictions
  • check spec for possibly missing special values (not necessary to merge PR though, can be added over time)
• ZHC
  • implement ties between exposes and spec where appropriate
  • automatically attach metadata to exposes (min, max, length, read, write, reportable, etc.), i.e. this and this
  • automatically attach special values (like done for colors & co), i.e. this
  • attachment process needs to be "far enough down-the-line" to be aware of custom clusters, but ideally a one-time thing
  • remove/update manual ZHC metadata as appropriate - stuff tied to spec, attributes & parameters, should no longer need manual metadata