A collection or index(es) will not be present in the latest checkpoint if it was created after the last checkpoint was taken. Attempting to open a WiredTiger checkpoint cursor on one of these would result in the following crash:

Failed to open a WiredTiger cursor. Reason: UnknownError: 2: No such file or directory, uri: table:{table_uri}, config: overwrite=false,checkpoint=WiredTigerCheckpoint

Instead of fassert-ing, like today when a cursor fails to open, an exception will be thrown instead for checkpoint cursors only.

When performing a background validation, if there is no check-pointed collection, then validation will return early. On the other hand, if there is no check-pointed index, skip that index but continue to validate the collection and other indexes.

We'll only validate the index(es) that are ready in the checkpoint and present in the in-memory index catalog (not dropped after the checkpoint) for the given collection.

With two-phase collection and index drops, the second phase of the drop is not performed (dropping the WiredTiger table) until the first phase (removing from MDB catalog and in-memory) is checkpointed. Thus, if the checkpoint lock is taken and the MDB catalog at the checkpoint time has an index entry, then the index table existence is ensured until the checkpoint lock is released and we shouldn't have a problem opening a checkpoint cursor on it.