Use merged-field counting for general query complexity limits - #4523

Extend Good Faith's merged-field calculation to general QueryComplexityLimits. Numeric defaults stay the same. Previously, general limits counted expanded AST occurrences independently of Good Faith's merged counts; now both use merged validation groups.

Which limits apply?

Limits apply independently to each operation in the validated document, including unselected operations.

Good Faith covers the whole mixed operation, including ordinary fields. Aliases/fragments and skipped root introspection selections also activate it. All branches count regardless of @skip/@include; variables are not coerced.

Good Faith permits at most one merged occurrence per operation of each: root __schema, root __type, __Type.fields, __Type.inputFields, __Type.interfaces, and __Type.possibleTypes. Aliases or distinct parent positions count separately toward these caps.

Configuration remains independent:

• Custom general limits apply normally; introspection takes the smaller of each configured limit and its Good Faith limit (500 fields / depth 20).
• QueryComplexityLimits.NONE disables general limits, but enabled Good Faith limits and coordinate caps still apply.
• Disabling Good Faith leaves general limits in place. Disabling both removes these complexity protections; parsing and ordinary validation safeguards remain.

How AST versus merged counting changes acceptance

Both object and leaf fields count. AST counting charges for occurrences, including repeated fragment spreads. Merged counting combines compatible fields and their children by response name and common parent at the same position. Aliases and different positions contribute separately.

With a general field limit of 2, the first two examples now pass; aliases still fail. Depth remains 2 in all three. Repeated-fragment trees can likewise pass despite exceeding the old expanded-AST budget. No separate expanded-AST field budget remains, including for introspection. Its existing Good Faith merged-count and coordinate protections remain.

Merged counting can also be stricter for abstract types. Suppose I is implemented by A and B, all have name: String, and their child fields return I, A and B, respectively; Query.node returns I:

{
  node {
    child { a: name b: name c: name }
    ... on A { child { name } }
    ... on B { child { name } }
  }
}

This counts 9 AST fields but 11 merged validation fields: the shared child selections contribute to both concrete-parent groups, giving 1 for node plus 5 per child group. A field limit of 9 therefore changes from accepted to rejected. These are validation-group counts, not ENO/runtime-type counts or estimates of list lengths and resolver cost.

Merge state remains document-wide; count summaries remain per operation. Depth is checked before child collection, and long counts prevent overflow. The separate application-specific QueryComplexityCalculator API remains available.