SERVER-81844 changed the ShardServerProcessInterface's create method to invoke the new _shardsvrCreateCollection path with unsplittable:true or invoke the explicit create depending on the upgrade/downgrade flags that were planned to be added in v8.0 (decision that is now being reverted).

Following discussions with kaloian.manassiev@mongodb.com, jordi.serra-torrens@mongodb.com and marcos.grillo@mongodb.com we convened that it is not necessary to rely on such parameters and that we can just rely on a new feature flag to be enabled in v8.0 to protect the new creation path.

The reasoning behind is the following:

• Mongos-es in v8.0 will always invoke the new path (that's correct because mongos are the last processes to be upgraded so we're sure shards can properly handle the request)
• Shard secondaries acting as routers will invoke the path depending on the fcv (that's correct as long as there is not a super-lagged secondary that did not replicate a FCV change on downgrade prior to switching other mongod binaries to the old version).

The worst case - in the very improbable scenario described above - would be that a collection creation passing through the ShardServerProcessInterface may fails with this error (so no data loss or catalog inconsistency).

Note that this can only happen if some on-prem user does not follow properly the downgrade instructions that in bullet (f) instruct to run some commands to make sure that FCV changes have been replicated to all replica-set members before switching binaries.