Recover to stable timestamp works by "pulling the rug out" from underneath in-memory state, which is constructed from the storage engine's data. To safely recreate the in-memory state, internal caches will be rebuilt. This includes rebuilding the "catalog". In short, this work should expose one method to throw away and one method to recreate the catalog. In between these methods, recover to a stable timestamp can "pull the rug out".

Requirements:

• Expose a method that destroys the catalog.
• Expose a separate method that reconstructs the catalog.
• After calling these methods, the catalog objects must be refreshed, sourcing their state from the current on-disk image, just as if this were startup.
• This includes:
  • Objects in the db/catalog directory, e.g: Database and Collection.
  • Storage engine implementations for DatabaseCatalogEntry and CollectionCatalogEntry.
  • Fixing up the UUID cache.
  • Refreshing [KV]StorageEngine internals. Possible relevant pieces for the KVStorageEngine.

Assumptions:

• It is sufficient to only implement the requirement for storage engine's that support recover to a stable timestamp (i.e: only KVStorageEngine).
• The code should assume (i.e: invariant) a Global X lock is held when entering both calls.

Constraints:

• The storage engine must not be destroyed.

Out of scope:

• For the purposes of this ticket, storage engine specific (i.e: WiredTiger, not KVStorageEngine) data only need to be addressed to give the implementor reasonable confidence the underlying storage engine is usable. For example, correctly regenerating internal state of specific storage engines (e.g: WiredTiger's SizeStorer), is beyond the scope of this ticket.