Refactor LwM2M engine to support tickless operation

[SeppoTakalo]

This is a combination of 3 changes that allows LwM2M engine to sleep longer without ticking 500 ms timer.

Create socketpair that can wake up zsock_poll()]

Allow socket-loop to wake up immediately, if there are changes,
instead of waiting for zsock_poll() to timeout.
This change makes engine more reactive and removes
hard coded timeout from zsock_poll().

New API (internal):

/**
 * @brief Trigger the LwM2M engine to run.
 *
 * This function wakes up ongoing poll() from the socket-loop.
 * It should be called when new transmissions are scheduled or service schedules are modified.
 */
void lwm2m_engine_wake_up(void);

Add support for non-periodic services

Engine now allows registering service callbacks that are
called only once on a given timestamp.
This allows tickless services to be developed.
New API proposed:

/**
 * @brief Call specific service handler only once at given timestamp.
 *
 * @param[in] service service to be called
 * @param[in] timestamp Time when to call
 * @return 0 for success or negative in case of error
 */
int lwm2m_engine_call_at(k_work_handler_t service, int64_t timestamp);

Refactor RD client to be tickless

Call RD client service only when there is state transitioning by using lwm2m_engine_call_at()
Remove periodic 500 ms timer.

When all these changes are combined, client will react to changes immediately as there is no 500ms timeout in zsock_poll(). Also it sleeps properly, when in QUEUE_RX_OFF. I measure the change on nRF9160. Current usage on sleep was reduced from 4 uA to 2 uA. So 50% power saving in sleep mode, where we are going to spend most of the time.

[SeppoTakalo]

Unfortunately this creates dependency to heap as the Socketpair uses heap to allocate storage.

Is this acceptable? I could refactor the socketpair to support statically allocated storage as well, if that would be preferred.

[SeppoTakalo]

I have a proposal that would allocate socketpairs statically on devices that don't define heap by default: #60914

[SeppoTakalo]

Power measurements of the changes in this PR

Measurements are done in nRF Connect SDK with these changes cherry-picked into the working tree. Target chip is nRF9160 and tool is Nordic Semiconductor Power Profiler Kit.

Client is configured to use LwM2M QUEUE mode and LTE modem is configured to use eDRX and PSM power saving modes.

Effect of these changes are clearly visible in the PSM power saving mode, where only thing that is constantly ticking in 500 ms interval is our LwM2M client. Floor current stays aroung 4 uA.

When client is re-build using tickless mode, those spikes in 500 ms interval disappear and the floor current drops below 2 uA.

Current main (without this PR)

This PR

[rlubos]

This is a significant improvement, however I'm wondering - perhaps we should retain the old behaviour (timeout-based poll()) as a Kconfig option? For the sake of platforms, that use socket offloading and are not able to use socketpair (i.e. offload entire poll() call).

[SeppoTakalo]

This is a significant improvement, however I'm wondering - perhaps we should retain the old behaviour (timeout-based poll()) as a Kconfig option? For the sake of platforms, that use socket offloading and are not able to use socketpair (i.e. offload entire poll() call).

I think this makes sense.
I can keep all the same APIs, but have Kconfig selection about tickless or interval based operation. The tickless operation would depend on NET_SOCKETPAIR. Interval based operation would leave the lwm2m_engine_wake_up() as an empty function and would just add 500 ms cap into zsock_poll() call.

[SeppoTakalo]

Updated the first commit, so there is now Kconfig option CONFIG_LWM2M_TICKLESS.
If it is not selected, maximum timeout for zsock_poll() is 500 ms. So it works almost like it used to be.

Btw. Whoever is reviewing, all 3 commits can be reviewed independently. I tried to separate the logical changes so that you can see what changes I did for engine, and what changes are done into RD state machine.

[rlubos]

Looks good, thanks. We should probably wait for conclusion on #60914 so we can get rid of heap dependency?

[SeppoTakalo]

Now that #60914 is merged in, this PR does not add any dependency to heap.

I rebased on top of main branch and added overlay-tickless.conf that can be used to enable the new operating mode.