sys/luid: Added postcondition to luid_get()

[maribu]

Contribution description

Stated the obvious in the doc: Altering the LUID returned by luid_get() breaks the guarantee that it is locally unique, as it than could collide with other LUIDs returned by luid_get().

Testing procedure

Read the new documentation and verify its correctness.

Issues/PRs references

Related to #12600, #12592. Incorrect users of this API have been identified by @benpicco in #12592

[benpicco]

If you grep for luid_get() you will find that all users (except for the one in random.c) will violate the API now 🤣

[maribu]

I truly believe that the added doc only clarifies what is already the case. So from my point of view this only makes it easier to notice that they all are violating the API.

But I assume this could be controversial in the context it now explicitly says all users but one of the API violate the API; so maybe ACK > 1 is needed.

[miri64]

This precondition makes it basically unusable for the originally intended use-case. ^^

[benpicco]

Adding luid_get_eui64() and luid_get_eui48() and converting the existing drivers to that is probably the only sane solution here.

Then this change should be uncontroversial.

[maribu]

I think it is useless for the apprently most common use case. The new doc will only point that clearly out.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[benpicco]

The description is still true though - and we have luid_get_eui64()/luid_get_eui48() now, so there is an alternative to the wrong use.

[fjmolinas]

Everything is green here, is there something blocking this still @miri64 @benpicco?

[miri64]

Nope, just fine IMHO. Let's just rerun Travis, to be safe.

[maribu]

Thanks for the reviews!