... with PITR

After PITR physical restore, there was inconsistent data between Primary
and Secondaries nodes.
The reason was that PITR oplog and dropping collections are applied in
reverse order:
- on Primary: [PITR oplog apply] -> [dropping PBM databases]
- on each Secondary: [dropping PBM databases] -> [catch up from Primary
including oplog apply]

Not using DDL operations (drop in this case) for PBM's system
collections fixes the problem.

That ensures that collection will not be created during PITR and by
doing that we eliminate the possible problem of having different UUIDs.

…hysical-restore

…hysical-restore