Fix: Enforce upper bounds for rxdelay, txdelay, and direct.txdelay

[kizniche]

Fixes #2433 by enforcing upper bounds for rxdelay, txdelay, and direct.txdelay, based on what is written in the CLI docs.

[dreirund]

Maybe increasing the limits can be useful? As There:
https://github.com/user-attachments/files/26126001/Proposal-.MeshCore.factors.in.selecting.rxdelay.txdelay.and.direct.txdelay.pdf (linked at #2053 (comment)) txdelay = 2.5 is also within the range of proposed settings.

Or just the documentation would need correction, whatever suits the intention?

[kizniche]

Perhaps changing the defaults is warranted, but something that should be discussed in the issue, not the PR. This PR is simply aligning the code with the expected behavior (the docs).

[CullenShane]

Denver already recommends values that are higher than these limits: https://denvermc.com/guides/repeater-setup

[dreirund]

Denver already recommends values that are higher than these limits: https://denvermc.com/guides/repeater-setup

So this PR would break existing use cases -- then I would say find the current maximum values and do a PR that aligns the docs with reality ;-).

[446564]

This should not be enforced in this way. There is no reason to have arbitrary limits, the only limit should be that of the underlying datatype. Why would we impose our own idea of a maximum on another user when it is not required for interoperability? There is nothing in the protocol or routing that this will have any effect on so there is no limit, again other than the underlying type which is likely very high (unreasonably so)

The limit should clamp to the max value for the type and the docs should be updated at the same time with maybe some language regarding a sensible value range.

[kizniche]

For rx, there's currently a hard 32 sec runtime cap, so the current 20 limit seems arbitrary. If it were to exceed ~62, then the 32 sec cap would come into effect. There's no runtime cap for tx, so high values create proportionately higher delays.

[446564]

For rx, there's currently a hard 32 sec runtime cap, so the current 20 limit seems arbitrary. If it were to exceed ~62, then the 32 sec cap would come into effect. There's no runtime cap for tx, so high values create proportionately higher delays.

i didn't dig too deep, but it seems going with the 32s makes sense for rx and tx i guess if someone wants to set 1000 they can, not that they should.

[kizniche]

Sounds reasonable. This would go nicely with additional documentation for tx/rx delay settings (#2431) so users would have some sort of guidance/bearing when changing settings.