During version upgrades, Atlas upgrades the binary version first while keeping the old FCV for a few days, then upgrades the FCV if everything works well. During this period of mixed binary version and FCV, new Atlas clusters (replset and sharding clusters) should run with the old FCV too.

Because mongod only starts with the FCV as same as its binary version, currently Automation Agent implements a workaround. Agent starts a new binary (e.g. 6.2) and then downgrades it to the old FCV (e.g. 6.1). This downgrade isn't safe because FCV downgrade may involve manual data manipulation, such as resetting the cap collection's size due to SERVER-67036. It caused issues in the linked tickets.

This happens when creating new clusters for customers and also for backup restores where they need to create an intermediate restore VM to prepare the restore collection data. 

It's possible to work around it by starting the old binary version and then to upgrade the binary to the latest version for new clusters, such that the old FCV remains. However, it's not only inefficient, but also complex since it's not trivial for the Agent to know if the cluster is new. MMS control plane knows whether a cluster is new but is supposed to only tell the Agent the end goal and let it to plan accordingly.

FCV is a state managed by mongod, so it is not ideal for its consumer to work around the mechanism in order to set it to a lower one. Instead, we should allow specifying the default FCV as a startup parameter. If no existing FCV is detected, the specified default FCV should be used instead of the same version as the binary. Thus, Agent just needs to provide the desired default FCV to the new clusters.

This should work for standalone, replica set and sharding clusters. 

We will need to make changes to https://github.com/10gen/mongo/blob/c6e5701933a98b4fe91c2409c212fcce2d3d34f0/src/mongo/db/commands/feature_compatibility_version.cpp#L432-L468. and take extra care that it works for sharding as well