Reduce critical section in rate limiter code

[MartinquaXD]

While investigating a deadlock which started happening recently [0] I noticed that matching on a temporary value extends that temporaries lifetime to the duration of the match statement. It can be extended even further when you return the match expression as a temporary value itself.
This is usually not a problem but can lead to surprising deadlocks when the temporary value contains a MutexGuard or something similar [1] [2]. Then the resource gets locked longer than expected.

I originally wrote the rate limiter code with the intention of NOT locking self.strategy for the entire duration of the log statement so it makes sense to fix that now.

However, I'm not convinced that this bug caused the investigated deadlock. The code always acquired the locks in following order 1. self.strategy 2. stdout and should have released it in the reverse order. For this lifetime extension to cause the deadlock there would also have to be a critical section which first locks stdout then self.strategy which I don't think it does anywhere.

Test Plan

existing tests

[vkgnosis]

The unexpected behavior around mutex guard temporaries is a good find and I like the change to make the behavior of the code easier to understand.
I also think that is not the cause for the deadlock because locking stdout is likely completely internal to the tracing functions.

[nlordell]

LGTM!