Users may be looking for other contextual information apart from just the representative query when using Persistent Query Settings. This could include use cases such as:

• Details about the incident that caused the setting to be applied in the first place.
• Details about the conditions for removing the setting.

In the context of backfilling it could also serve as a mechanism for users to track queries yet to be backfilled. 

IDL Changes
**

Every command in MongoDB supports 'generic arguments', one of those is 'comment' field (https://github.com/10gen/mongo/blob/83a6e0f7a03ced072a7e75522b778799e114a6ab/src/mongo/idl/generic_argument.idl#L126-L130)

While setQuerySettings command is no exception, as part of this task we would want to add the 'comment' field to the settings, as opposed to the command.

This way, when listing the settings via $querySettings agg stage, we can see the corresponding 'comment' field associated with settings

Acceptance criteria

• Extend the query settings object to also contain a `comment` field
  • The comment field should accept any type.

• After running setQuerySettings({..., comment: "I'm a comment!"}), users should see this field in:
  • $querySettings - The comment field should be visible inside the query settings object itself.
  • explain - When running explain over a query which contains query settings, the comment field should be visible if it exists.

• The comment field inside a query settings object should not affect the plan cache key.
  • Expect the query settings hash with and without the comment field to be equal.
  • Expect the PlanCacheKey with and without the comment field to be equal.
  • This should be a unit test.

• Users shouldn't be able to set query settings with just a comment field.
  • Query settings should always contain on of: indexHints / reject / queryFramework.
  • The comment field shouldn't be taken into account when calculating if a query setting is a default value.

• Users should be able to update a comment field.

• • When the previously set query setting doesn't contain a comment field.
  • When the previously set query setting did contain a comment field.

• Users should be able to remove a comment field by setting it to an empty object {}.{}
  • When simplifying, the comment field should be set to boost::none when faced with an empty object {}.

• Ensure that this is marked as downstream changes, so the documentation team is aware and can react accordingly.