In drop_pending_retry, we try to execute the following sequence:

// Mocks WT returning EBUSY when dropping the table.
assert.commandWorked(primary.adminCommand({configureFailPoint: "WTDropEBUSY", mode: "alwaysOn"}));                     

assert.commandWorked(db.createCollection("toDrop"));

assert.commandWorked(db.createCollection("toWrite"));

const collUri = getUriForColl(db.getCollection("toDrop")); 
const indexUri = getUriForIndex(db.getCollection("toDrop"), /*indexName=*/ "_id_");

assert(db.getCollection("toDrop").drop());

// We need to perform this write so that the drop timestamp above is less than the checkpoint 
// timestamp. 
assert.commandWorked(db.getCollection("toWrite").insert({x: 1}));

// Take a checkpoint to advance the checkpoint timestamp. assert.commandWorked(db.adminCommand({fsync: 1})); 

This insert command should advance the stable timestamp, so that when the checkpoint is taken in the fsync command after it, the checkpoint is taken at the same optime as the insert command and after the optime of the drop command.

However, in the attached BF we saw that for some reason at the time that checkpoint was taken, the stable timestamp had not advanced to the optime of the insert as we expected.

This ticket will add checks for the last committed, last applied, and all durable timestamps (the stable timestamp is the minimum of these 3) and check that these values all advanced as expected. This way, if the BF is encountered again we will have additional logging and information on what went wrong.