[3.x.x] Fix some federated tracing issues (ExpediaGroup#963)

* Rename federation to federated

* Update docs

* Add federation tracing enable/disable

* Add new configuration properties for tracing

* Update config to default to true and use headers

* Add integration test for federation tracing

* Update spring config docs

Co-authored-by: Shane Myrick <[email protected]>

[plugins] allow renaming of the downloaded/introspected schema (Exped…

…iaGroup#956)

Simplifying Maven plugin configuration by allowing customizing the downloaded/introspected schema file name. Current logic did not allow renaming the default file (from `target/schema.graphql`) and required explicitly specifying the schema file for the client generation mojo. This was confusing as when `download-sdl`/`introspect-schema` mojo was used together with `generate-client` one we had to specify target schema always pointing to the default one. Updated logic so that specifying custom schema file name will now apply to all tasks. `generate-client` mojo was also updated to use default `target/schema.graphql` file if schema file is not specified.

In order to keep it consistent, Gradle `downloadSDL` and `introspectSchema` tasks were updated to allow specifying custom `outputFile`s from `build.gradle`.

[3.x.x/plugins] backport fix for generation of self referencing types (…

…ExpediaGroup#949)

* [3.x.x/plugins] backport fix for generation of self referencing types

See: ExpediaGroup#948 for details

* fix failing unit test

Update error message for invalid field selection (ExpediaGroup#936)

Co-authored-by: Shane Myrick <[email protected]>

[3.x.x][generator] Only add directives with valid locations (ExpediaG…

…roup#924)

* Only add directives with valid locations

When generating a schema you can have an annotation on any part of the schema, assuming you haven't set the Target, so if you are restricting the directive locations to only specific places they may still be added to the schema and then fail generation as they are added to invalid locations. While this could be viewed as a customer error, this is more of an issue with graphql-kotlin because we can have input and output objects with the same directives and things like the KeyDirective from federation are only valid on output. So in that case we shouldn't fail if someone uses the type as input elsewhere, it will still not be marked as a federation type for the input

* Rename function name

* Add unit tests for coverage

Co-authored-by: Shane Myrick <[email protected]>

[plugin] improve client generation exception handling (ExpediaGroup#915)

* [plugin] improve client generation exception handling

Changes
* use typed exceptions instead of generic `RuntimeException`
* validate whether fragments are valid

Related: ExpediaGroup#903

* fix ktlint

* Apply suggestions from code review

Co-authored-by: Shane Myrick <[email protected]>

* fix code to use updated exception

Co-authored-by: Shane Myrick <[email protected]>

[3.x.x] backport fixes for client concurrency and custom scalars bug (E…

…xpediaGroup#917)

3.x.x backports:
* ExpediaGroup#913
* ExpediaGroup#916

[plugin] update Gradle plugin extension to use Actions (ExpediaGroup#901

)

* [plugin] update Gradle plugin extension to use Actions

Originally extension was using Kotlin lambdas for some configuration which worked fine when used from Kotlin script (`build.gralde.kts`) but it could not be easily used from Groovy scripts (`build.gradle`). By changing from lambda with a receiver to a Groovy Action the resulting code will be translated using SAM conversion that makes it possible to configure the extension using Kotlin lambda or Groovy closure.

Resolves: ExpediaGroup#893

* fix ktlint violations

[server] update to SpringBoot 2.3 (ExpediaGroup#898)

* [server] update to SpringBoot 2.3

Also updates Jackson dependency to `2.11.3`.

Resolves: ExpediaGroup#850

* add missing validation dependency and cleanup spark dependencies

[client] fix generation of duplicate classes (ExpediaGroup#883)

* [client] fix generation of duplicate classes

We were incorrectly using simple class name for the type lookup as all classes are wrapped in some root type (i.e. `Query.MyClass`) whereas GraphQL type name was just the actual type. We were also incorrectly comparing selection sets as we were not unwrapping selection sets of the children fields.

Fixes: ExpediaGroup#864

* fix caching and correctly compare selection sets of different types