Align WorkQueueBuilder with new workqueue work timeout feature

[bjarki-andreasen]

The feature comes with a new parameter to be initialized using the WorkQueueBuilder.

[d3zd3z]

Thank you for your contribution. I am actually in the midst of a bit of an overhaul of how the workqueue code works, so we'll have to rework this a bit at that point.

Probably my main concern is that with the current code, the work will actually get leaked if it is aborted due to a timeout. I'll try to think if there is a way to deal with this.

One thing I have planned to add is to allow my new struct Work to be passed as &'static Work, which would make the lifetime issues less of a concern.

[d3zd3z]

I think the only practical way to get this into both Zephyr and Rust is going to be to add the support based on some conditional (CONFIG_HAVE_...) so that the rust code will compile either way. It is too constraining to be practical to try and push these together lock step.

[bjarki-andreasen]

I think the only practical way to get this into both Zephyr and Rust is going to be to add the support based on some conditional (CONFIG_HAVE_...) so that the rust code will compile either way. It is too constraining to be practical to try and push these together lock step.

Modules in zephyr constantly need to be updated and synced, this is not an issue :) The process is this:

1. create PR which changes zephyr module (Rust)
2. create PR for zephyr which does two things:
   • update zephyr manifest to point to Rust PR
   • adjust zephyr to match changes in zephyr module (Rust)
3. Wait for green CI in zephyr, which means zephyr and the changes to the module work together.
4. Merge PR for zephyr module (Rust)
5. update zephyr PR to point to the new Rust sha
6. Wait for green CI in zephyr
7. Merge zephyr PR

The problem here is that the module itself is running its own CI, against an incorrect version of zephyr, IE, not the one being created in step 2.

The CI in this PR here should be ignored, as it is not tracking zephyr.