Replica set nodes started with --shardsvr create their KeyManager and LogicalTimeValidator when they are added to a cluster and initialize their sharding state, unlike config servers, standalone replica set nodes, and mongos, which create them up at startup. So before being added to a cluster, any request from a user other than __system that gossips a clusterTime will be rejected with ErrorCode::CannotVerifyAndSignLogicalTime, because there is no validator available. This was masked in v3.6, because we only validated or signed logical times if FCV was fully upgraded to 3.6, and shard servers default to FCV 3.4 after a clean startup.

Once we remove these FCV checks in SERVER-32463, we'll have a problem in our test infrastructure, because when calling ShardingTest with replica set shards and a keyfile, the shell briefly authenticates as __system and receives a dummy signed clusterTime from the newly set up shard (because times aren't signed for internal clients) and then calls awaitSecondaryNodes on the shard without authenticating as __system and will attempt to gossip a clusterTime and will be unable to receive an ismaster response from each secondary, causing the test to timeout.

This may be desired behavior, but we still need to untangle this from FCV, since currently the implementation details of upgrade/downgrade determine how clusterTime is handled and those checks will be removed before the next release.