sys/xtimer: deprecate for 2023.04

[MrKevinWeiss]

Contribution description

Now that we have ztimer running on all RIOT applications we should simplify
and only use ztimer.

Testing procedure

Read the docs? Check to see if you have a message in the make -C tests.

Issues/PRs references

[MrKevinWeiss]

This was done in the General Assembly while talking about deprecation. I am sure we all wanted this...

[MrKevinWeiss]

When I have time I think I will swap all the xtimer APIs out from the examples.

[benpicco]

I think the xtimer compat header could be kept and used as a convenience API (see #17330) for code that should work no matter if ZTIMER_MSEC, ZTIMER_USEC or some other future ztimer backend is compiled in.

e.g. xtimer_msleep(10) will use ztimer_sleep(ZTIMER_MSEC, 10) if ztimer_msec is used, but will gracefully degrade into ztimer_sleep(ZTIMER_USEC, 10000) if that is not the case.

[MrKevinWeiss]

Does it make sense to add the notice separate from the swapping of the API? I feel like it would be nice to get this in the release and I don't know how long it will take me to swap all the xtimer stuff we have.

[MrKevinWeiss]

I think the xtimer compat header could be kept and used as a convenience API

I haven't looked into it but one reason I really want to get rid of xtimer is to make it easier to model. If it is a simple thing, then sure that makes sense. If it is one of those things that only recursive make + luck to not hit a race condition can solve than I may push back.

[MrKevinWeiss]

We should come to a conclusion before the release.

Can we deprecate while still having USEMODULE += xtimer in the repo?