Best effort attempt to keep backwards compatibility while making immutableTs lock validation optional on reads.
If a read is performed without validating immutableTs lock on a thoroughly swept table, there is no guarantee on
consistency of data read; as sweep may remove data that is being read. This will not cause any correctness
issues as immutableTs lock will be checked on commit time, and transaction will be aborted if lock is invalid.
Although this prevents committing corrupted values, reading inconsistent data may cause tasks to throw
non-retriable exceptions; causing a possible behaviour change.
This wrapper task will convert the exception thrown by the underlying task into a retriable lock timeout exception
if immutableTs lock is not valid anymore.