In shards and config servers the featureCompatibilityVersion is available. This is however not the case for mongos which is currently uses the featureCompatibilityVersion correlated to its binary.

This causes a problem in causal consistency as mongos will be trying to sign the outgoing requests and will block waiting on the keys. This is not acceptable as the upgrade process may take very long time. Its possible that user upgrade the binaries but never issue setFeatureCompatibilityVersion command. So polling is not a good idea for mongos to discover its version.
To address that mongos will:
At startup check for keys. If no keys are found then mongos will eventually be checking for keys every 10 minutes (its already default behavior)
Check for keys immediately if the incoming messages contains proof to validate (its already default behavior)
If keys were never found do not add $logicalTime and operationTime to the command Response (its new)

This way mongos will eventually start using causal consistency within 10 minutes of actual upgrade.