tolerate bad collection metadata produced on version 2.4 or earlier

The collection creation path in versions 2.4.x and earlier persisted any unknown collection options in the catalog. Due to the changes SERVER-25459, recent versions of master will reject these unknown options. This causes mongod to fail during startup with fatal assertion 18523, as in the following:

2016-10-11T11:30:13.901-0400 I -        [initandlisten] Fatal assertion 18523 InvalidOptions: The field 'badOption' is not a valid collection option. Options: { badOption: "foo" } at src/mongo/db/storage/mmap_v1/mmap_v1_database_catalog_entry.cpp 876

It could also cause 3.4 secondaries replicating this metadata to shut down with a fatal assertion.

In order to make it possible for affected deployments to smoothly upgrade to 3.4, the 3.4 node must be able to tolerate extant bad metadata while also rejecting any new collection creation requests which include a bad option. Luckily, collections created on 2.4 or earlier can be identified by the fact that 2.4 also materialized the create field as the first BSONElement in the catalog metadata. Versions 2.6.x and later neither materialized the create field nor wrote unknown collection options to disk. (2.6 through 3.2 ignored unknown options but did not write them into the catalog, whereas 3.4 will reject unknown options entirely.) Therefore, only collection metadata documents which begin with the create field can include unknown options. A 3.4 node can simply ignore unknown fields during collection parsing only if the create field is present.

Going forward, we could eliminate bad collection metadata entirely by creating a command or startup flag that traverses the catalog and strips out any unknown fields. This work is out of scope for this ticket.