Cluster server parameters also need to be synchronized from the CSRS to mongoses on sharded clusters. Unlike replica sets, there is no way to monitor a source of truth on disk and make in-memory changes appropriately. Therefore, mongoses will have to run a periodic job in the background that polls for updated parameters. The frequency of these checks will be bounded via a new setParameter, clusterParameterStalenessIntervalSecs. The periodic job will also be triggered every time a new clusterParameterTime is gossiped in.

1. Define a new node-specific server parameter, clusterParameterStalenessIntervalSecs, that is used to bound the maximum amount of time between consecutive runs.
2. Create a polling job that runs on a background thread and runs a find command filtering on documents with clusterParameterTime greater than the largest clusterParameterTime the mongos has cached locally.
3. Update the in-memory ServerParameters affected by the reply.
4. Write a unit test to ensure that the polling job works as expected.