Add graphql instruments

[BrynCooke]

This PR adds GraphQL instruments to telemetry as a commercial feature.

It makes the following possible:

telemetry:
  exporters:
    tracing:
      propagation:
        trace_context: true
    metrics:
      prometheus:
        enabled: true

  instrumentation:
    instruments:
      graphql:
        # The number of times a field was executed (counter)
        field.execution: true

        # The length of list fields (histogram)
        list.length: true

        # Custom counter of field execution where field name = name
        "custom_counter":
          description: "count of name field"
          type: counter
          unit: "unit"
          value: field_unit
          attributes:
            graphql.type.name: true
            graphql.field.type: true
            graphql.field.name: true
          condition:
            eq:
              - field_name: string
              - "name"

        # Custom histogram of list lengths for topProducts
        "custom_histogram":
          description: "histogram of review length"
          type: histogram
          unit: "unit"
          attributes:
            graphql.type.name: true
            graphql.field.type: true
            graphql.field.name: true
          value:
            field_custom:
              list_length: value
          condition:
            eq:
              - field_name: string
              - "topProducts"

This reuses the schema aware zipping that has been developed for cost control to visit response documents and create metrics.

New selectors are:

• graphql.type.name
• graphql.field.type
• graphql.field.name
• graphql.field.length

And new standard instruments are:

• field.execution - The count of times a field was returned in responses by field name and containing type
• list.length - A histogram of list lengths by field name and containing type

Follow ups:

• documentation and changelog is not added as part of this PR and will be done separately.
• Refactor some code to bring it out of the cost module as it is shared across cost and telemetry.

---

Checklist

Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.

• [ ] Changes are compatible[^1]
• [ ] Documentation[^2] completed
• [ ] Performance impact assessed and acceptable
• Tests added and passing[^3]
  • [ ] Unit Tests
  • [ ] Integration Tests
  • [ ] Manual Tests

Exceptions

Note any exceptions here

Notes

[^1]: It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. [^2]: Configuration is an important part of many changes. Where applicable please try to document configuration examples. [^3]: Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions.

[github-actions[bot]]

@BrynCooke, please consider creating a changeset entry in /.changesets/. These instructions describe the process and tooling.