fix Incorrect timeout error when using FindStringMatch()

[Brinenas]

fix Timeout Error issue: when the fastclock stop running, then next matches will get a wrong fast.current and daeline, thus trigger an incorrect timeout error.

[ccoVeille]

LGTM 👍

but I would expect some tests to be provided with the fix. It would avoid errors in any future refactoring

[Brinenas]

Add a new UT, If you comment the add code, the ut will failed.

[dlclark]

Thanks for submitting this. Can you add an integration-level test showing the behavior fix from the API consumer perspective?

[Brinenas]

Add a new UT for my own case. Maybe you guys can add a more elegant test.

[dlclark]

@Brinenas a couple issues I see:

• fast.running and fast.start are protected by fast.mu for read/write, so we can't access them without getting the lock
• I don't think we want to get that lock every time we need to make a deadline because this is an edge case. I've refactored the code to only do this if we already know the deadline needs to be extended.

I did a couple other small tweaks to the test as well. Let me know if you see any issues with my change.

[bradrevans]

This change fixed a similar issue for me - intermittent false timeouts seemingly triggered by a large volume of sequential regex matching that appeared after the inclusion of the fast clock back in v1.8.0. Appreciate theres probably a lot of other stuff on your plate but was wondering when we might be able to expect a new tagged release including this fix? Thanks for the effort on resolving this! <3

[dlclark]

@bradrevans this is done.

[bradrevans]

@bradrevans this is done.

Ah. Thanks!