The file write_ops.idl contains the data types that the router uses to communicate with shards for writes.

 The struct UpdateOpEntry encapsulates the information needed for a shard to execute an update. We will add an optional boolean flag to tell the shard to append metrics to its response.

UpdateOpEntry: 
  # ...
  fields: 
    # ... pre-existing fields ...
    includeQueryStatsMetrics: 
      description: "If true, add query stats info to the response for this update operation."
        type: bool
        default: false
        stability: internal

We may also decide to put this flag into WriteCommandRequestBase in order to allow the other write commands request metrics as well.

Similarly, for the response struct we add new fields to store the metrics. We will declare a new struct type StmtCursorMetrics that may optionally be added to UpdateCommandReply. This type is an optional array that contains the index of the statement for which metrics have been collected and the metrics themselves. This approach allows a sparse representation of metrics that we expect to be collected infrequently, and follows a similar pattern to other fields.

structs: 
  # ...
  StmtCursorMetrics: 
    description: "CursorMetrics for a single update statement."
    fields: 
      index: 
        description: "Index of the statement in the command."
        type: int
        stability: stable
      cursorMetrics: 
        description: "CursorMetrics object."
        type: CursorMetrics
        stability: stable
  
  UpdateCommandReply: 
    # ...
    fields: 
      # ...
      cursorMetrics: 
        description: "Cursor metrics for update statements that request it."
        type: array<StmtCursorMetrics>
        optional: true
        stability: internal

We may also decide to put cursor metrics into WriteCommandReplyBase instead.

Because the new fields to existing structures are all optional, it should be safe to update the IDL files, and only use the new fields in a later issue. No feature flag checks should be required.