In follower mode, WT can only satisfy timestamped reads back to the oldest_timestamp of the installed checkpoint. Thus there is a risk that the server might install a checkpoint that has an oldest timestamp after the transaction timestamp of an active reader on the follower node. In that case the transaction could read incorrect data.

This is unlike the behavior on leader nodes, or in traditional WT, where the pinned timestamp ensures that WT never throws out data that an active transaction might need to read.

To avoid this problem WT should refuse to install a checkpoint if the checkpoint's oldest timestamp is more recent than the oldest transaction timestamp in the system.

For this ticket it is sufficient to 

1. Detect the situation where the server tries to reconfigure a new checkpoint and the checkpoint has an oldest timestamp that is more recent than a running transaction.
2. If this happens, the reconfigure call should fail with WT_PANIC, essentially killing the system.

In the future we will want the error handling to be smarter. Either

• WT finds and kills the offending transaction(s)
• WT returns a non-fatal error, allowing the server to either delay installing the checkpoint, possibly after finding and killing the offending transaction(s) at its level.

In other words, in the future this guardrail will only come into play if the something goes wrong.