Concurrent modifications succeed in pessimistic cache

During node crash, two concurrent modifications in can both succeed in pessimistic transactional cache.

This would cause an inconsistent change of an entry. There is a small timeframe where this can happen as the first transactions must start before the node crash and commit after a successful rebalancing.

1. TX1 originating on node A acquires lock for key X, node A is primary owner
2. node C is killed and node B becomes primary owner of key X
3. TX2 originating on node B acquires lock for key X, node B is (now) primary owner
4. TX1 commits the tx, prepare-Tx is sent with the new topology id so it commits fine
5. TX2 also commits the transaction