Double Check Wrapping Behavior of Timers

[bjoernQ]

Several functions include blocking behavior or generally deal with timers - double check them for the wrapping behavior of the timers
Also note that the timers on different targets have different bit-widths

[bugadani]

I still wouldn't consider this issue solved, but

cc esp-rs/esp-wifi-sys#313 especially esp-rs/esp-wifi-sys@43a4cec

Speaking of the overflowing timeout checks, I'm not sure I got all places where this could pose an issue, but probably most of them. In one place we can't use the convenient elapsed_since function, because the timestamp calculation on Xtensa SoCs is not sounds if called inside a critical section (at the moment of an overflow, the cycle counter and the global overflow counter will be out of sync).

The wifi driver uses 32-bit values with varying units of measurement, which represent a range of:

• ~107 seconds (@ 40MHz tick rate) or ~142 seconds (@ 30MHz tick rate after Xtensa: Set up time slice before switching task, tweak tick rate esp-wifi-sys#323) in ticks
• A bit more than an hour in microseconds

Often the driver converts times into ticks then passes those ticks to esp-wifi, but not always - it's a bit of a mess. I'm not entirely confident in what time spans we can receive from the wifi stack, to be honest. It's probably fine for block times, but I'm not sure how beacon timeouts are handled, for example, and those are user configurable to some degree.

[bjoernQ]

We are now using esp_hal::time::current_time under the hood which should wrap earliest every 7 years (depending on the target). There is still some code to cleanup but I guess we can close this