kernel: work: triggers immediately with longer timeouts

[anicare-tero]

Describe the bug
There seems to be a bug when using kernel works. With functions like k_delayed_work_submit_to_queue(), the work triggers immediately with longer timeout values.

I have tested it with a lot of different timeout values. A Nordic employee has debugged the issue more and his results are shown in the thread below.

See the thread on Nordic DevZone about the issue:
https://devzone.nordicsemi.com/f/nordic-q-a/60303/nrf9160-device-functionality-after-a-week

To Reproduce
Steps to reproduce the behavior:

1. Get the project from the DevZone thread (.zip file as an attachment)
   'Loop start'
2. Test different timeout values
3. Build the project
4. Flash the project into the board (nRF9160 DK)
5. See error
   'Loop end'

Expected behavior
For example, with k_delayed_work_submit_to_queue(&my_work_q, &my_device.work, K_MINUTES(1440)); the work triggers immediately.

Impact
This issue is not keeping me stuck but it has done my project code a little more complicated. First I thought I was doing something wrong but then it turned out there might be some bug on Zephyr.

Environment:

• OS: Windows 10
• Toolchain: nRF Connect SDK
• Commit SHA: master branch - https://github.com/nrfconnect/sdk-nrf/commit/a11e9443b5572dec149f13051f5edb698b57f632

[carlescufi]

@anicare-tero I believe this is already fixed in master, but not in NCS yet (#26248).
Also might be related to #19075

[anicare-tero]

@carlescufi Yes, you seem to be right. I will be waiting for the fix to be pushed to NCS. Thanks!