gnrc_ipv6_nib: use recursive mutex instead of mutex for locking

[miri64]

Contribution description

This should make the problem that popped up in #12408 easier to solve. There, since the source address detection accesses the NIB's prefix list interface now to determine the prefix lengths of given addresses. This deadlocks its internal process, however, since this function is also called by the neighbor solicitation send function from within the NIB. With a recursive mutex this can't happen.

I also made the mutex itself private and implemented two functions two lock/unlock it from the outside, which scraped of some 100 bytes of ROM on Cortex M0+.

Testing procedure

make -C tests/gnrc_ipv6_nib flash test

and

make -C tests/gnrc_ipv6_nib_6ln flash test

still pass, pinging between two gnrc_networking instances works.

Issues/PRs references

Preparation for a rework of #12408.

[benpicco]

The first thee commits might as well be one.
Unless there ever is a case where the IPv6 thread intentionally blocks on itself, this should not change the behavior of the current code.

As I'm not sure if this is the case (thread blocks on mutex_lock() to be woken by another thread) I'm not ACKing yet - but if you reassure me no such construct is used, this should be good.

[miri64]

The first thee commits might as well be one.
Unless there ever is a case where the IPv6 thread intentionally blocks on itself, this should not change the behavior of the current code.

That is the problem in #12408.

As I'm not sure if this is the case (thread blocks on mutex_lock() to be woken by another thread) I'm not ACKing yet - but if you reassure me no such construct is used, this should be good.

No, that is not the point of that mutex. It is just for access protection (since the NIB can also be accessed e.g. by the shell or the application).

[miri64]

The first thee [sic] commits might as well be one.

Nah, this makes the change more comprehensible.

[benpicco]

The mutex is only used for mutual exclusion and not for signalling, so replacing it with a recursive variant is safe.

[miri64]

Restarting Murdock, as the last build was quite old.