Clock trait

[kaczmarczyck]

Implements a Clock trait for CTAP

Replaces #453 and #468.

This is an overview for discussion, to be split in its commits for submission:

1. CtapState etc. is generic over Env
2. Intoduces a Clock trait and implements it in both Envs
3. Uses the Clock

This PR replaces all existing timers and clocks in src/. It also removes the embedded_time dependency. It is arguably making the code simpler by only offering relative time outside of debugging. There are 2 design choices I want to discuss before submission:

A)

There are no timestamps outside of debug (and those are named as microseconds). All durations are always milliseconds, and this is implicit and typed as usize for simplicity. I don't think that's necessarily bad, but to capitalize on compile time checking, we have 2 other options:

• Introduce a DurationMs type
• Reuse the libtock-drivers Duration type

Do you think that's worth it?

B)

This PR doesn't change any behavior, with one exception: Before, we passed around timestamps that were measured once and then constant throughout a command. Now when we check or create timers in one command, they are off by however long the computation in between took. I don't think that's a problem, but we could emulate the old behavior if we wanted to.

On a side note, another change in behavior: The HID timestamps should be more robust against clock wrapping now. We now have a central place to prevent clock wrapping issues, so all affected timestamps should be fixed now.

Opinions?

[ia0]

I think it's fine to submit as a single PR. I would not try to split.

Regarding the questions:
A. I think using usize for timestamps in milliseconds is fine as long as naming of functions and parameters reflect it (which seems to be the case for the parts I have reviewed).
B. I think that's fine. Those timers are not meant to be that precise.

Overall I think it's the right direction. My main concern (which is very localized so doesn't impact the design) is how the clock is actually implemented. I only reviewed the key files and didn't went through the full PR yet.

[ia0]

I only reviewed the API change. If the PR is in a submittable state, then I can review the rest.

[kaczmarczyck]

Go ahead. I tested on the development kit and timers are still working as expected.

[ia0]

LGTM, mostly 2 nits:

1. Documenting time unit, either in the name or in the documentation.
2. Relying on type inference to improve readability. The code has only one environment at runtime, so it should be as implicit as possible.