ipc: do not hold a spinlock when calling schedule_ipc_worker()

[kv2019i]

Calling schedule_ipc_worker() with spinlock held is not stricly required. schedule_ipc_worker() calls k_work_schedule_for_queue() and the Zephyr workqueue has an internal lock protecting the workqueue structures. Keeping spinlock held during the call does lead to complex scenarios to debug and verify as schedule_ipc_worker() itself is dispatched from a work queue.

Simplify the flow and release spinlock before rescheduling the worker. In ipc_work_handler(), this leaves a small window where the message is just sent after we release the spinlock, and before we call schedule_ipc_worker(). This is however harmless, as in worst case the IPC worker is woken up one extra time.

[Copilot]

Pull Request Overview

This PR refactors the IPC (Inter-Process Communication) code to avoid holding a spinlock when calling schedule_ipc_worker(). The change simplifies the locking flow by releasing the spinlock before scheduling work operations, which prevents complex debugging scenarios since schedule_ipc_worker() itself is dispatched from a work queue.

Key changes:

• Move schedule_ipc_worker() call outside the spinlock in ipc_msg_send()
• Refactor ipc_work_handler() to use a local boolean flag to defer the scheduling call until after the spinlock is released
• Add explanatory comments about the potential harmless race condition

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[kv2019i]

Discussed with @lyakh . He'd like to see a concrete case where this causes failures and I don't have one at this point. Putting as draft for now to prevent merge until we have better consensus.

[lgirdwood]

good optimization.