Large device frame counter gaps may trigger device default channels to be re-enabled

Summary

As part of the L2 1.0.4 specification, the backoff procedure of the ADR algorithm mentions that once the default data rate has been reached, and the Network Server has not responded to ADRACKReq, the end device will re-enable all of its default channels, and reset the transmission power index and number of transmissions:

Our stack does not recognize that this event occurs, and it will not correct the end device channel mask when it occurs.

Steps to Reproduce

Join an end device on SF10 in US915.
Unplug the gateway.
Allow the end device to send ~96 uplinks.
Re-plug the gateway.

Current Result

The LNS does not correct the end device channel mask, even though the end device has reset it.

Expected Result

The LNS should realize that the end device may have re-enabled all of the default channels, and re-patch the channel mask.

Relevant Logs

No response

URL

No response

Deployment

The Things Stack Enterprise (self-hosted)

The Things Stack Version

v3.24.2

Client Name and Version

No response

Other Information

No response

Proposed Fix

We need to keep the last FCntUp which has been observed without the ADRACKReq bit set. This allows us to compute the theoretical gap in which the end device has not received a downlink that confirms that the connectivity is available.
If the end device is on the default / minimal data rate (note that this is a set, because some regions have two default data rates depending on the join considerations), and the gap is larger than ADR_ACK_DELAY, mark all of the default end device channels as enabled.

Contributing

[X] I can help by doing more research.
[X] I can help by implementing a fix after the proposal above is approved.
[X] I can help by testing the fix before it's released.

Code of Conduct

[X] I agree to follow TTN's Community Code of Conduct.

TheThingsNetwork / lorawan-stack