Optimistic write skew and clustered expiration can have some weird issues

One such is:

The issue is the following:

1. RemoveExpiredCommand reads the expired from the container with version 1 and puts in its context
2. PutKeyValueCommand sees nothing in container due to expired and adds a new entry with version 1 in its context
3. Put gets the lock and replaces the value
4. RemoveExpiredCommand attempts to run and because it saw the old value the lifespans still match (if different)
5. Then the write skew passes for the remove expired command since the value in container and its context both have version 1

To workaround this for now we should prevent a get of an expired entry from returning early when using optimistic transactions.