**
After SERVER-81188 we extended _shardsvrCreateCollection to include the fields of the {create..} command. In order to keep the 2 requests as uniform as possible we changed the type of the field “collation” from “BSONObj” to “Collation” in both shardCollection and _shardsvrCreateCollection.

However, in case of change_streams_downgrade suite on an implicit multiversion variant, we are experiencing many failure due to the following interleaving:

1. Start case: mongos 7.0 and shard 7.2 with empty collation: Since the variant failing is implicit multiversion we know mongos can be still in 7.0 talking to a 7.2 shard.
2. Run “shardCollection” : the collation is simply forwarded as set in the original cluster request. The collation can be forwarded as empty bson object and then parsed as Collation object on the shard side. This will apply the default values of the Collation type and being stored in the ddl document as non-empty object.
3. Case forced step-down: mongos 7.0 and shard 7.0: The collation is now parsed as bson object on the shard side. The non-empty request stored in the ddl document will be loaded as non-empty bson. The original request, now re-tried by the 7.0 mongos will come again as a empty bson, causing the checkIfOptionConflict to fail

This ticket is to revert back the following fields type on _shardsvrCreateCollection:

• collation from Collation back to object_owned
• unique from default=false back to optional=true
• presplitHashedZones from default=false back to optional=true