Contribution description

Currently, most functions that might reschedule contain logic that enables them to be called with interrupts disabled. This is not only going against the scope disabling interrupts in the first place, but also doesn't work. All these functions end up calling thread_yield_higher(), which will fail to suspend the current thread.

Depending on the use-case, this can be more or less catastrophic. If the tread doesn't go to sleep, thread_yield_higher() will just trigger the switch once the interrupts are enabled (although on some architectures this might be bad due to unflushed instruction caches - see the cortex m code). But if the thread is set to go to sleep, the current thread will continue execution although it shouldn't. For example, the following assertion will be triggered:

    static cond_t cond = COND_INIT;
    static mutex_t lock = MUTEX_INIT;

    mutex_lock(&lock);
    irq_disable();
    cond_wait(&cond, &lock); // this should block forever
    assert(0); // thread_yield_higher() couldn't trigger the interrupt

This breaks both program logic and leaves the scheduler in a messed up state.

⚠️ For this PR, I simply grepped for thread_yield and removed any IRQ state saving logic wherever thread_yield*() was found and the code is clearly not allowed to be executed from IRQ context, so don't expect it to be comprehensive. There might still be places that I missed and still feature useless IRQ state saving logic.
I also added an assertion in thread_yield_higher() s.t. if it's executed in thread context, the interrupts must be enabled.

The case of the mutex

mutex_lock() really shouldn't be called with interrupts disabled, as it reschedules. However, it's fine to do it if we know there is no thread blocking on that mutex. This is the case of vfs_bind_stdio(), which is called in early init, with interrupts disabled.

I therefore left the mutex the way it is. The assertion in thread_yield_higher() will still catch a reschedule.

Testing procedure

I run the automatic tests on native, and I get some failures (see comments).

Issues/PRs references

#20940