Redis may have several calls to mstime() in a single command which is inefficient and may lead to bugs (most commands don't really need to get a super-fresh time when they call mstime())

@antriez suggested in https://github.com/antirez/redis/pull/6861:
We should have access to different mechanisms. I want to given an example of what we can do:

1. mstime() -> This should be used when we really need the current time.
2. loop_mstime() -> This should be a cached value that we refresh always in afterSleep(): this way we know it is not an outdated information. This should replace all the accesses to server.mstime that we do now when we don't need a very fresh time.
   On top of that, both these calls should no longer use gettimeofday() but a monolithic clock. Then we should use one call or the other, depending on how much freshness we really require. But I bet we'll be able many many times to use the cached value, because the value cached in this event loop cycle is fresh enough for a number of uses.

Moreover, we should check RTSC that is in new processors finally fixed about the multi core issue that plagued it for ages, in order to use that instead in many places, or even more interestingly, just to provide a very powerful cached_mstime() that is able to update it automatically when the RTSC timer signals that there is too much delta compared to when we refreshed it.

So this is a thing that we should handle in a proper way during the start of a major release, like in Redis 7.