If prepared rollback or commit race with checkpoint, we may end up having history store records with max stop timestamp in that checkpoint but no prepared update in the data store.

Commit scenario:
We mark the update as committed. Checkpoint runs on the page and write the committed value and the history store record of that key that still has the max stop timestamp.
The rollback logic fixes the stop timestamp in the history store.

Rollback scenario:
We append the value from the history store to the update chain and mark the prepared update as aborted. Checkpoint runs writing the history store value to the data store and the same history store value with max stop timestamp to history store. We come back and delete the value from the history store.

Rollback scenario2:
We append the value from the history store to the update chain and mark the prepared update as aborted. Other sessions commit new updates to the key. Checkpoint runs writing the newest value to the data store and the same history store value agin with a new entry that has a higher unique counter and the entry that still has a max stop timestamp to history store. We come back and delete the entry with the max timestamp from the history store.