Rewrite time driver

[bugadani]

This PR does a few things:

• Reduces the use of critical sections
• Moves the interrupt handler and/or the associated timer into Alarm, so that we don't have to maintain an array of handlers, and we don't have to index to access initialized timers.
• Uses embassy's (un)safety requirement to avoid a null check when calling timer callbacks.
• Checks if there are enough timers to initialize the pre-allocated alarms
• Creates the alarms array with a macro, so that we don't have to manually define interrupt handlers.
• Bonus change, though it's not needed with the last commit: #[handler] functions can now be references in const context.
• The PR also adds a basic embassy benchmark and slightly optimizes the thread-mode executor, though I can submit that separately if needed.

[bugadani]

Ran the added benchmark on 0.22 and this PR:

0.22: INFO - Test OK, count=26628, cycles=45065/100
PR: INFO - Test OK, count=26616, cycles=45085/100
PR with Relaxed memory ordering: INFO - Test OK, count=27535, cycles=43580/100

This isn't surprising as the benchmark doesn't rely on the time driver, but at least it also means that set_alarm(u64::MAX) didn't get worse.

[bugadani]

Acquire ordering doesn't make sense here - there is no matching Release store to define a happens-before relationship with. However, for some inexplicable reason, this measures to be slightly faster than Relaxed. Manually adding a memw instruction before a Relaxed load is significantly worse, so the change with this ordering is likely non-local.

[bjoernQ]

Is the benchmark supposed to stay or is it a temporary thing?

[bugadani]

I'd like to keep it around

[bjoernQ]

I'd like to keep it around

Just asking because it looks a bit out of place here. I'm also wondering if we should have more benchmarks (for other things) in general and if we should have such a thing in parallel to qa-test and hil-test (maybe not part of this PR)

[bugadani]

Just asking because it looks a bit out of place here. I'm also wondering if we should have more benchmarks (for other things) in general and if we should have such a thing in parallel to qa-test and hil-test (maybe not part of this PR)

I guess it fits well enough into qa-test, I'll move it.

[MabezDev]

LGTM!

btw did we ever explore placing the executors in RAM? Maybe in this basic bench it won't make a difference, but I can imagine in a bigger app with esp-wifi etc it might.

[bugadani]

btw did we ever explore placing the executors in RAM?

Not really, but performance isn't exactly the point of this PR, just a bit of an extra.

I guess we can try, but I'm also hesitant to auto-respond with "just place it in RAM" to perf issues. It may help, but eventually we'll run out of ram. We also can't place everything in RAM - we can't just inject a macro into embassy-executor for its various functions - namely wake_task, or Executor::poll.

[bjoernQ]

Somewhat off-topic but I am thinking about a way to allow users to freely configure placing things in RAM - I should create an issue for that