pkg/lwip: fix netdev concurrency issues

[jia200x]

Contribution description

This PR fixes a concurrency issue in LWIP, as a result of calling netdev functions from different context.
Traditionally our netdev driver model assumes implicitly that all netdev functions run on the same thread. As it is now, LWIP calls all send functions from the caller thread (e.g main), but processes ISR on a higher priority thread. This not only creates concurrency issues in existing devices, but renders other modules such as the SubMAC unusable...

To (temporally) solve this, I implemented some recursive mutex lock functions to acquire the device before calling any internal operation. In the future it would be better to schedule all transmissions from a single thread.

Although this won't make the current situation worse, I'm assuming LWIP uses mutex internally to prevent concurrency issues between LWIP functions called from different context. If this doesn't hold, we will need to proceed with the single thread solution.

EDIT: I also adapted the netdev return calls to the newer API. Returning 0 is not considered an error anymore (which is what netdev_ieee802154_submac does).

Testing procedure

Test that LWIP still works as expected (e.g tests/lwip).

Issues/PRs references

Found while porting the KW2XRF to LWIP #18465

[jia200x]

Although this won't make the current situation worse, I'm assuming LWIP uses mutex internally to prevent concurrency issues between LWIP functions called from different context. If this doesn't hold, we will need to proceed with the single thread solution.

@miri64 does this assumption holds?

[maribu]

lwIP internally synchronizes all acceses via a global lock and all internal functions assert that the lock is taken when they are called. I guess that lock is implemented via a mutex in RIOT, but I haven dived deep enough into the implementation to say be sure.

[maribu]

ACK. Code looks good and I trust your testing.

I believe this can fix a lot of sporadic and hard to reproduce issues.

[maribu]

Suggested change

There already is an empty above

[chrysn]

This has been requested for backporting. I don't see the big picture of its complexity yet, but am marking it for "needs backport" if only to make sure I'll have it in the "known issues" section.

[jia200x]

amended and squashed direclty