Lingering timekeeping bug on samd?

[jepler]

After #6202 I think there's a (new! but extremely implausible) scenario where time will fail to progress. Adding back some form of the RTC interrupt would fix it, but the details got a bit messy as I considered them. Rather than try to fix this even rarer and even easier to work around bug (just call time.monotonic daily!) we decided to take #6202 and file this bug.

Basically, imagine a program that goes through the following steps:

• records a starting time
• waits for an event to occur, without calling any time-related functions that ultimately call _get_count
• records an ending time
  If the time for the event to occur is "very long", it is now possible for the RTC's 32-bit counter to overflow without an interrupt; it is _ticks() being called that records the overflow, and it can only detect a single overflow.

It appears that "very long" is equal to one overflow-time of the RTC counter, since overflows are detected with a simple "<" condition. So, for instance, if the counter started at 0x1000_0000, progressed to 0xffff_ffff and rolled to 0x0000_0000, then progressed to 0x1000_0001 before the external event occured, CircuitPython on samd would now record an event of just 61us instead of 3.03 days.

Any affected user code could be fixed by ensuring that time.monotonic() or other time-checking routine is called anytime during the long wait.

Initially it's tempting to just restore the RTC overflow interrupt and change it so that it just calls _get_count(NULL). However this still leaves a bug: we've seen that the pre-rollover value of COUNT.reg during the RTC overflow interrupt can vary. If in one RTC overflow interrupt it was 0xffff_fffd and then in the next overflow (3 days later) it was 0xffff_fffe then the rollover would still be lost. Is there something else we can 'easily' do, such as cause one 1-ms tick from the overflow interrupt (which would "certainly" occur after the "true" wraparound), and then call _get_count() from a background task?