Add pre-merge validation rule to ensure that there are no missing field arguments

[glen-84]

Probably similar to External Argument Missing, but for all fields (not only external fields).

[PascalSenn]

This issue highlights a gap in validation that arises when arguments - both required and optional - are mismatched across subgraphs. While schemas can technically compose, the ambiguity in expected execution behavior can create runtime challenges.

The Problem:

From a technical perspective, fields with differing arguments are still considered equal as long as their return type and shared arguments are compatible. However, this equivalence introduces ambiguity in execution behavior when arguments differ.

Example with Required Arguments:

# Schema A
type Example {
    field(arg1: String!, arg2: Int!): Int
}

# Schema B
type Example {
    field(arg1: String!): Int
}

In this case:

• arg2 is required in Schema A but absent in Schema B.
• Technically, the fields are equivalent since the argument mismatch does not break composition.

However, when a query provides arg2, what should the gateway do?

1. Always route to the schema with the most arguments (Schema A)?
   This ensures the query can be executed but could bypass subgraphs like Schema B, even if they are valid for simpler cases.

2. Always route to the schema with the least arguments (Schema B)?
   This simplifies routing logic but risks runtime errors if required arguments like arg2 are not handled.

3. Route dynamically based on the provided arguments?
   This is the most flexible but introduces complexity in routing logic and execution semantics.

Example with Optional Arguments:

# Schema A
type Example {
    field(where: Filter): [Values]
}

# Schema B
type Example {
    field(order: [OrderBy]): [Values]
}

Here, both where and order are optional arguments. While the schemas compose:

• Queries providing both where and order result in undefined behavior:
  • Schema A ignores order.
  • Schema B ignores where.

The ambiguity raises similar questions:

1. Should the gateway prefer subgraphs supporting the most arguments (where + order)?
   1.1 What if there is not full match?
2. Should the gateway fallback to simpler fields that ignore arguments?
3. How should the gateway handle cases where arguments impact response semantics, such as filtering or sorting?

Open Questions:

1. Should validation enforce stricter rules about argument alignment across subgraphs?
2. Should the gateway adopt a clear strategy for routing:
   • Prefer schemas with the most arguments?
   • Prefer schemas with the least arguments?
   • Route dynamically based on provided arguments?
3. For optional arguments, should the gateway warn or error if their usage could lead to undefined behavior?

[PascalSenn]

The assumption here was wrong. Arguments & Input Objects should be merged by intersection