Support directives on the schema

[oryan-block]

Fixes #717
Fixes #729

Checklist

• Pull requests follows the contribution guide
• New or modified functionality is covered by tests

Description

Directives on schema @foo { ... } and extend schema @foo were never read, so they didn't end up in GraphQLSchema.getSchemaAppliedDirectives(). For Apollo Federation v2 this means extend schema @link(...) was missing from federation-jvm's _service.sdl, and the gateway treated the subgraph as Federation 1. They're now added as schema applied directives, the schema definition's first, then its extensions' (same order as graphql-java's SchemaGenerator).

Also fixed RootTypeInfo taking the last SchemaDefinition. SchemaExtensionDefinition is a subclass of it, so schema { query: MyQuery } followed by extend schema @foo lost the custom root type and failed with "Type definition for root query type 'Query' not found". Operation types are now merged across the definition and its extensions.

Only applied directives are set on the schema, not the deprecated legacy withSchemaDirectives. graphql-java doesn't resolve type references in that list, so a directive with an enum argument (e.g. @link(..., for: SECURITY)) failed schema validation with a ClassCastException. getSchemaDirectives() returned nothing before this change either.

SchemaObjects gets a schemaAppliedDirectives property, defaulting to empty. @JvmOverloads and a hidden copy() overload keep the old constructor and copy() signatures, so code compiled against 14.0.x still works.

Checked end to end with federation-jvm 6.2.1 (on graphql-java 25, since that's what it's built against): the _service.sdl now has the @link, and on master it didn't.

Behaviour change: a directive on schema / extend schema that isn't declared, or uses an argument its definition doesn't have, now throws a SchemaError like it does everywhere else. Before, it was silently dropped. This also means federation users who declared @key etc. but not @link will need to declare @link too. The existing SchemaClassScannerTest federation fixture had exactly that problem (it applied import: without declaring it), so I fixed it.

Undeclared directives, like the @link-imported ones in the last comment on #717, still fail by default. For #729 there's a new allowUndeclaredDirectives option: directives without a definition are then added as applied directives, with argument types guessed from their values like in 13.0.1. They're not added as legacy directives, since graphql-java rejects those without a definition. Enum and object values can't be guessed, so those still throw and ask to declare the directive.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud