Correctly implement the cpuRateLimit feature

[tomaka]

Correctly implements #2151

The code currently does u32::max_value().checked_sub(rate_limit). This is wrong, it should be checked_div.
I remember that when I was testing #2151 I was doing u32::max_value() / rate_limit, and then at the last second before opening the PR I replaced this with the checked_ function in order to handle the situation where rate_limit is 0.

In addition to fixing this mistake, I've also changed the code to use floating points instead of integers.
Right now the precision is actually very low: because we round the division to the nearest integer, the possible values for the CPU bound can only be 100%, 50%, 25%, 12.5%, etc. Using floating points fixes this.

[mergify]

Automatically approving tomaka's pull requests. This auto-approval will be removed once more maintainers are active.

[tomaka]

Note: I've intentionally left this in the demo so that it mimics what substrate-connect will now do (paritytech/substrate-connect#900)

[melekes]

👍

[melekes]

Suggested change

	if !(after_poll_sleep < max_duration_float) {
	if after_poll_sleep >= max_duration_float {

[tomaka]

So this is intentional because it's not exactly the same!
If after_poll_sleep is NaN, then !(after_poll_sleep < max_duration_float) will be true but after_poll_sleep >= max_duration_float will be false.
It's not super important because it's never supposed to be NaN, but IMO it doesn't hurt to have it this way.

[melekes]

is there a guidance on when to use debug_asserts? don't you think they tend to clutter the code?

[tomaka]

I don't think I've written this down, but I use them for internal-bug-detecting purposes.
In other words, what you put in the debug_assert! is something that, if false, indicates that there's a bug in the internal logic of the current module.
However if it's an incorrect API usage, then it should be assert! instead.

The reason is that incorrect API usages tend to happen not because of silly programming mistakes but because it's sometimes hard to understand or keep in mind how the API that you're using is supposed to be used, and thus are more likely to happen and to pass code reviews.

[github-actions]

twiggy diff report

Difference in .wasm size before and after this pull request.

---

 Delta Bytes │ Item
─────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
        -393 ┊ <smoldot_light_wasm::cpu_rate_limiter::CpuRateLimiter<T> as core::future::future::Future>::poll::hd1b3692f1a559a7f
        +335 ┊ core::time::Duration::from_secs_f64::h6350bd82a690aa63
        +274 ┊ <smoldot_light_wasm::cpu_rate_limiter::CpuRateLimiter<T> as core::future::future::Future>::poll::h637b1d9f092ce30e
        -269 ┊ <smoldot_light_wasm::platform::Platform as smoldot_light_base::Platform>::now_from_unix_epoch::h2cb6578f5b4acc50
         +83 ┊ core::ptr::drop_in_place<smoldot_light_wasm::cpu_rate_limiter::CpuRateLimiter<core::future::from_generator::GenFuture<smoldot_light_wasm::init::init<alloc::vec::Vec<futures_util::abortable::AbortHandle>,smoldot_light_wasm::platform::Platform>::{{closure}}>>>::hedc2b33abe2a5ffb
         -75 ┊ core::ptr::drop_in_place<smoldot_light_wasm::cpu_rate_limiter::CpuRateLimiter<core::future::from_generator::GenFuture<smoldot_light_wasm::init::init<alloc::vec::Vec<futures_util::abortable::AbortHandle>,smoldot_light_wasm::platform::Platform>::{{closure}}>>>::hd5f4a881f3302fb8
         +18 ┊ init
         +34 ┊ Σ [7 Total Rows]