We now have 3 more audit events that need to be documented, and one existing audit event that now has one more field than it previously did.

The new audit event `atype`s are `getClusterParameter`, `setClusterParameter`, and `updateCachedClusterServerParameter`.

For `getClusterParameter`, the param is `

{ "requestedClusterServerParameters": <requested parameters> }

`. The result is always 0 - success.

For `setClusterParameter`, the param is `

{ "originalClusterServerParameter": <old cluster param value>, "updatedClusterServerParameter": <new value set by client> }

`. The result is always 0 - success.

For `updateCachedClusterServerParameter`, the param and result code are the same as for `setClusterParameter`. The difference here is that this event gets audited whenever a parameter is changed in-memory, which may be due to propagation of a `setClusterParameter` command, due to a replication event such as rollback, or (on mongos) due to the periodic refresher learning of new cluster parameter values from the config server.

Additionally, the param for the existing audit event with `atype` `startup` has been changed. Now, the param appears as follows: `

{ startupOptions: <document>, initialClusterServerParameter: <list of documents> }

`. `startupOptions` contains all of the options that the node was started up with (this was previously associated with the field name `options`). `initialClusterServerParameters` contains the initial values of the cluster server parameters that the node has at the end of startup, after they have been loaded from disk (in the case of mongod) or refreshed from the config server (in the case of mongos).

Description of Linked Ticket

We should audit the values of cluster server parameters at startup. We should also audit when any cluster server parameter is updated in-memory via setClusterParameter. Finally, we should audit when cluster server parameters are retrieved via getClusterParameter.