Feat: Add decaf zero-timeout value

[h3lix1]

Add 0x000DECAF as the reserved "actual zero" timeout value for config fields where 0 means "use the default". Default::getTimeoutMs() maps the DECAF value to 0ms and otherwise keeps the existing configured-or-default behavior.

PowerFSM now uses the helper for:

• display.screen_on_secs
• power.min_wake_secs
• power.wait_bluetooth_secs

Built locally for seeed-xiao-s3.

This is part of the ESP32 Power Saving series of diffs.

🤝 Attestations

• I have tested that my proposed changes behave as described.
• I have tested that my proposed changes do not cause any obvious regressions on the following devices:
  • Heltec (Lora32) V3
  • LilyGo T-Deck
  • LilyGo T-Beam
  • RAK WisBlock 4631
  • Seeed Studio T-1000E tracker card
  • Other (please specify below)
    Seeed XIAO ESP32S3

[ianmcorvidae]

Just to be potentially frustrating (sorry!), I really don't like the magic value approach where it's not needed, and at a protobuf level it really isn't here, because the property could be set optional, which creates an explicit 0 separate from the unset/missing value. The question would be the client side there, I guess, so I wonder if @garthvh and @jamesarich have any thoughts there (I hereby give permission to pester me aggressively to implement it in the CLI if anything in settings comes to use it)

[h3lix1]

@ianmcorvidae I'm onboard with this, although I'll need to see where else in the code this is used. It's pretty extensive how much default==0 is used today.

I'll need to validate unsetting values isn't problematic to make them defaults over all the different clients, etc. The probability of creating a ton of bugs is probably high, especially with interactions between old clients and new protobufs. I.e if an old iOS client with old protobuf thinks 0 is default and new node sees 0 as literal 0, there will be breakage.

I'd recommend this for the next API breaking change.. maybe 3.0 where we will likely require everything to upgrade together. I can put a TODO together for when this happens.

[garthvh]

Seems unnecessary what is the problem being solved here? Why not just use the optional functionality that already exists and maps directly to the protobuf transport?

[h3lix1]

@garthvh The problem is to set a 0 value for things to sleep immediately after servicing a packet.

The challenge is that 0 means default, thus there is no easy way to set 0 for an immediate sleep.

Exasparating the challenge is that the Android and iOS client use 0 as "unset".

Changing this behavior will require changes to iOS, Android, and likely the CLI to start treating 0 as 0 and unset as default. For FixedUpdateIntervals.kt line 46 has:

UNSET(0L, textRes = Res.string.interval_unset)

or

FixedUpdateIntervals.unset is 0 in IntervalEnums.swift

So in order to change this behavior, it will require updating the firmware to treat both 0 and unset/undefined as default, wait a majority of nodes to upgrade, update all the cilents to use unset the values as optional, wait for everyone to update their clients, and then update the firmware to treat literal 0 as 0.

I don't mind playing the long game to do the correct thing, but until then, using 0x000DECAF will bypass months of waiting for everyone to upgrade.