lwm2m: report acknowledgement of notifications to app

[huelsenfruchtzwerg]

Right now the application has no way of knowing whether the server has received data. PR #36453 added a callback to inform the application of timeouts, but it doesn't trigger on successfull delivery/acknowledgement.

I believe there are (at least) two valid use cases for this:

1. The app wants to "go sleeping" (i.e. turn of the modem) when all data has been delivered successfully.
2. The app wants to know whether the lwm2m library is still functioning correctly to for example feed a watchdog. We still observe some sporadic deadlocks of the nrf_modem_lib for example which completely halt the lwm2m thread, but the app has no way of knowing this.

[rlubos]

I think that a reasonable approach would be to replace lwm2m_notify_timeout_cb_t with a generic lwm2m_observe_cb_t, that would allow the application track all of the observe-related events such as:

• New observation
• Cancelled observation
• Successful notification delivery (as requested in this PR),
• Timeout
• Other errors (?)

The question rises whether this should be handled by a separate callback. or rather to extend the existing list of events, but IMO it'd make sense to separate the observe related-stuff from the registration related events, monitoring such events would be optional then for interested parties only.

[JPSELC]

I think a key thing here is to allow the application to track notifications from creation to acknowledge or timeout via this generic lwm2m_observe_cb_t
When a notification is sent, the lwm2m obj path, token and msg pointer are available.
However when acknowledged, only the token is available, and when timeout, only the msg pointer is available

[huelsenfruchtzwerg]

I like the idea.

However when acknowledged, only the token is available, and when timeout, only the msg pointer is available, and when timeout, only the msg pointer is available

I don't quite understand this. E.g. the path is available at the time the acknowledgement is received. Or are you saying this information should be withheld intentionally, to "force" the app to keep track of the precise notification/ack pair if it want's to know what was acknowledged?

[JPSELC]

When an acknowledge is received it refers to the token. You can perhaps look up the token to see what path it corresponds to, but if you want to go to sleep you will have to ensure that the latest notification is acknowledged, that is, track each notification to acknowledge or timeout. It's not enough to know the path if you have the potential for multiple notifications from that path.

[MaikVermeulen]

If everyone is okay with it, I would like to pick this up in light of #32610 .

[MaikVermeulen]

For everyone interested:

Currently on Github I see that there are 3 or so issues all related to buffering/handling intermittent connectivity.

For focussed discussion, I think it would be nicer to have a central thread on it.
I’ve made a thread ‘Client offline mode, data buffering, etc.’ in the LwM2M channel on the Discord.