Optimizations will be:
* multiple set() values (with the same expiration) will be applied in a
single setMulti()
* for a set() followed by another set() on the same key, only the latter
one will be applied
* same for an replace() followed by an increment(), or whatever operation
happens on the same key: if we can pre-calculate the end result, we'll
only execute 1 operation with the end result
* operations before a flush() will not be executed, they'll just be lost
Rollback strategy includes:
* fetching the original value of operations prone to fail (add, replace &
cas) prior to executing them
* executing said operations before the others, to minimize changes of
interfering concurrent writes
* if the commit fails, said original values will be restored in case the
new value had already been stored
This class must never receive invalid data. E.g. a "replace" can never
follow a "delete" of the same key. This should be guaranteed by whatever
uses this class: there is no point in re-implementing these checks here.
The only acceptable conflicts are when cache values have changed outside,
from another process. Those will be handled by this class.