The approach in TOOLS-1813 turns out to have a number of edge cases that need to be fixed.

For mongodump:

• Ensure UUIDs are dumped to collection metadata (probably just writing a test for existing behavior) (TOOLS-1815)
• Ensure an error occurs if rename is seen during oplog dumping (probably just confirming existing tests/behavior) (confirmed)
• Ensure an error occurs if FCV is modified during oplog dumping (new behavior) (TOOLS-1818)
  • A shortcut might be to error on any modification to admin.system.version

For mongorestore:

• Add a --preserveUUIDs flag (TOOLS-1817 – may come after 3.6 GA unless we can fit it in)
• With --preserveUUIDs, have the following behaviors:
  • Require the --drop flag or abort
  • Require collection metadata to contain UUID info or abort
  • Require the destination to be in FCV 3.6 or abort (MUST check both ways that FCV could appear)
  • Create collections with the desired UUID with a synthesized applyOps command
    • Follow procedure in SERVER-31906 for creating admin.system.version with a given UUID
  • Apply oplog without modification
• Without --preserveUUIDs, have the following behaviors:
  • Strip UUID information when creating missing collections (probably just needs a test confirming restored collections are different)
  • When applying oplog entries, remove UUID related fields
    • Remove top level 'ui' field
    • Remove ‘o.dropTarget’ in op:’c’ entries where ‘o.renameCollection’ exists
    • Recurse stripping into nested ops in op:'c' entries where 'o.applyOps' exists