From BF-31587, this sequence of events can occur:
1. Create a collection with namespace “a” at time 1
2. Start dbcheck at time 2
3. Drop the collection at time 3
4. Create a view with namespace “a” at time 4
5. Primary dbcheck oplog entry at time 5 for namespace “a”, but with read timestamp at time 2 (while namespace “a” is a collection)
6. Secondary tries to apply this dbcheck oplog entry at time 5, but during general oplog application code (before we reach the dbcheck specific code), we check if the namespace is a view or not. This seems to be done with no read timestamp (set here), so then we fassert because this namespace is a view and applyOps is not allowed on a view.

We should look into if we can skip the fassert if the operation is dbcheck, as once we reach the dbcheck specific code, the secondary should then use correct read timestamp at time 2, when the namespace was still a collection. But we should double check if we are always guaranteed to get the stashed catalog at our requested read timestamp. If not, we should modify the secondary to catch the error and log the same warning message about the CommandNotSupportedOnView as we do on the primary