[FEATURE] ⏲ Better timestamping

Problem

FusionCache currently does not keep track the logical moment when a cache value has been set the first time. This can useful in general, and in particular for example in scenarios like when comparing 2 different entries, both stale, one found in the memory cache and one in the distributed cache: one may be more fresh than the other, so FusionCache can decide which one is better to use.

Solution

Add an internal Timestamp property to each entry, with the value being when the entry has been logically created. Here "logically" means not when the entry instance has been created, but the original one: for example when an entry is taken from the distributed cache and ported over to the memory cache in a typical "get" flow (first check memory cache, then distributed cache, then copy over the data) the timestamp should remain the one found in the distributed cache, so that it represents the point in time of when the cached value has been created.

This can also be useful in scenarios when multiple nodes may call the factory in rapid succession, very near in time between each others: with this new piece of information FusionCache can make better decisions on what to keep and what to use as the most fresh piece of data.

Additional context

Because of gradual upgrades and the way some serializes work, it has been observed that it would be better to make the field nullable and handle the null case explicitly, otherwise there may be problems while updating to the new version of FusionCache for existing users with an already populated distributed cache, containing entries serialized with the old format that may have problems deserializing in the new format.

ZiggyCreatures / FusionCache