There are various places in the cloner where we call createCollection, instead of userCreateNS (and without the original collection options) which can lead to the collection not containing the same options.

While it is unlikely these places will ever be exercised in real/production use due to the failures plus timing required to trigger them, it is good we clean it up for consistency and accuracy. The only reproduction I could come up with for this would be if a user dropped the collection in the split instant when the cloner releases the lock between creating the collection and starting the copy of the data/indexes-defs. In order to test this fix it was required to manually error during earlier collection creation calls to test all code paths.

If encountered the behavior can affect replication, or any other use of the cloner like copydb, or cloneCollection. for example.