Remove dead code from the __checkpoint_worker preamble, we should never be asked to checkpoint a file for which there's no metadata entry.

@agorrod, michaelcahill – I was looking at f597615 and something occurred to me. In __checkpoint_worker there's this code:

/*
 * Get the list of checkpoints for this file.  If there's no reference
 * to the file in the metadata (the file is dead), then discard it from
 * the cache without bothering to write any dirty pages.
 */
if ((ret = __wt_meta_ckptlist_get(
    session, dhandle->name, &ckptbase)) == WT_NOTFOUND) {
        WT_ASSERT(session, session->dhandle->session_ref == 0);
        return (__wt_cache_op(session, NULL, WT_SYNC_DISCARD));
}

Is it possible a change on a file's page might not be globally visible after its metadata entry has been removed?

WT_SESSION.drop of an object closes the open handles before it removes the object from the metadata, which means that if the object has been modified, we're going through the checkpoint code as part of closing open handles while there's still a metadata entry, so there's no problem there.

Is there any way you can remove an object from the metadata without closing all of its open handles? (Closing open handles is key, of course, because a checkpoint looks for open handles, not entries in the metadata.)

If the answer is "no", I think this code is dead and should be removed, we should never be checkpointing an object that doesn't appear in the metadata.

If it's possible to remove an object from the metadata without closing all open handles first, I think there's a problem, because the new check in *evict_file could return EBUSY on a file being discarded via the *checkpoint_worker function.

This code has been in the tree since this function was first written, and I'm suspicious it's a holdover from when checkpoint was more involved in discarding files from the cache. So my guess... is that this code is dead.

Reference WT-1299.