time: positively check the deadline before reading the state of TimerEntry in Sleep

[wathenjiang]

This is for fixing the issue #6545.

[wathenjiang]

It seems the in virtualized CI environments, if the time of Sleep is too short, then we might encounter unexpected Ready.

I don't know much about the testings of metrics, and I don't know what would happen if I removed its dependency on Sleep.

However, I believe that increasing the time of Sleep can greatly solve this problem.

[Darksonn]

Long sleeps in tests are a big problem for us because they make CI take really long. I don't want to increase them.

In general, I don't think I want to make this change. It fixes the precise case that you are referencing, yes, but it does not fix the slow task polls issue. I don't think it's worth it, and I don't want to make timers slower (see #6504).

[wathenjiang]

Yes, you're right. This small patch is limited in solving slow task balls issues. Due to my belief that Sleep has provided the following guarantee: assuming the deadline is reached, then get ready from polling it. I consider that doing so may be beneficial in such similar use case.

I think increasing the time of CI is very bad, but it seems that after patching, some CIs will directly return Ready just in the first poll of Sleep. Perhaps the problem does not lie in this patch, but rather in the fact that metrics testing may not rely on Sleep.

On the other hand, it seems that we may not be able to exhaust such scenarios. For example, networks seem to have similar issues as well. For example, users may observe byte data in the read buffer of a Socket, but find that their socket read operation has not been returned.

In the end, I agree with your point of view. Telling people what blocking the thread is currently the least complex way.