As described in WT-18396, WiredTiger depends on WT_SESSION::drop to return EBUSY if a table has any uncheckpointed data, so that we don't have to enforce careful ordering of drop's and checkpoint's schema epochs to prevent an impossible situation, in which the caller is requesting WiredTiger to checkpoint previously uncheckpointed data for a table that no longer exists.

WT-18396 ensured that we handle this correctly on a leader; now we need to ensure that it works correctly on a follower. WT_SESSION::drop on a follower has to reject dropping a table that has any committed data that is not covered by a checkpoint that it picked up from the leader.

Otherwise if the follower drops a table and steps up, it would not be able to create a checkpoint if the drop needs to be deferred past the checkpoint due to its schema epoch.