Fix lazy evaluation pattern in rate limit decay

[andygolay]

Fix lazy evaluation pattern in rate limit decay (problem 2 in https://www.notion.so/movementlabs/OFT-issues-2ae18675b2d780af9013ee9082afccdd)

• Remove min() cap on elapsed time calculation in in_flight_at_time to allow decay to continue beyond one window, preventing in_flight_on_last_update from getting stuck above the limit when the limit is lowered
• Clean up Move warnings

[rubujubi]

Regarding this commit 4f52b70

Just want to confirm that we allow rate_limit.in_flight_on_last_update to be greater than rate_limit.limit right? Then it makes sense to remove the cap here.

My current understanding is that when rate_limit.limit is suddenly lowered the current fix can let rate_limit.in_flight_on_last_update decay proportionally to the updated rate_limit.limit instead of getting stuck, however having a lower limit still make the process slow, and if we want to speed up the process we should increase the limit.

[andygolay]

Regarding this commit 4f52b70

Just want to confirm that we allow rate_limit.in_flight_on_last_update to be greater than rate_limit.limit right? Then it makes sense to remove the cap here.

My current understanding is that when rate_limit.limit is suddenly lowered the current fix can let rate_limit.in_flight_on_last_update decay proportionally to the updated rate_limit.limit instead of getting stuck, however having a lower limit still make the process slow, and if we want to speed up the process we should increase the limit.

@rubujubi yes, we could increase the limit to speed it up if needed.