[4.2] Opening a transaction at the all durable timestamp can go backwards

SERVER-41766 introduced ghost timestamps on a primary for multi-statement transactions doing a multikey write. This causes WT's perspective of the all durable timestamp to go backwards.

To compensate, the method to get the all durable that the storage engine exposes ensures the value does not go backwards.

However, the 4.2 version of reading at the all durable timestamp uses the API that can go backwards. This can result in causal reads not seeing their own writes when they are concurrent with other writers flipping multikey inside a multi statement transaction. Reading at the no overlap, however does use from the safe API.

4.4 (and master) use the WTKVEngine call which protects them from this bug.