Call hooks for return type on properties (ExpediaGroup#1112)

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

[build] update release build to automatically release to nexus (Exped…

…iaGroup#1093)

This is a follow up to ExpediaGroup#1091 which seems to be working fine.

[client] generate enums in UPPERCASE and fix kotlinx request serializ…

…ation (ExpediaGroup#1087)

Update client generation logic to always generate enums in UPPERCASE and then use corresponding Jackson (`@JsonProperty`) or kotlinx-serialization (`@SerialName`) annotation to convert those back to expected schema values. This allows us to support enum values that cannot be used directly in Kotlin (i.e. `name` and `ordinal`) as they would clash with built in methods.

This PR also resolves incorrect serialization of requests when using `kotlinx-serialization`. We were applying our custom `AnySerializer` to serialize the requests which was in turn incorrectly serializing enums and custom scalars. I changed the logic to construct correct `KSerializer` based on the specified request.

Resolves: ExpediaGroup#1075

[plugins] update plugins to allow generation of client code using kot…

…linx serialization (ExpediaGroup#1070)

This is a third and final PR in a series to introduce support for both `Jackson` and `kotlinx.serialization` data formats for GraphQL Kotlin clients.

This PR updates Gradle and Maven plugins to allow generating client data models supporting both formats. This PR also updates Ktor client to by default depend on `kotlinx.serialization` instead of `Jackson`.

Large size of the PR is driven primarily due to the formatting fixes in the Gradle plugin integration tests (updated build scripts templates to use `trimMargin` for consistent indentation).

Related:
* ExpediaGroup#1048 - this is an attempt to split it up to more manageable pieces
* ExpediaGroup#1066 - first PR in the series
* ExpediaGroup#1069 - second PR in the series
* resolves ExpediaGroup#929 - add support for generating `kotlinx.serialization` data models

Generate context with suspend and nullable in subscriptions (ExpediaG…

…roup#1053)

* Generate context with suspend and nullable in subscriptions

* Update tests

* Do not cache null context for subscriptions

* Rename internal methods

* WIP

* Update subsctiption javadocs

* Use expression body

* Update docs for context

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

Generate DataLoaders on every request (ExpediaGroup#1040)

With the introduction of the new KotlinDataLoader interface we made the way to get the data loaders a property. However taking the advice from graphql-java we should generate each DataLoader every request. The factory generates the registry for every request currently but the data loaders themselves would still be static.

This also updates the docs and examples around data loaders from the last PR

[server] support batch requests (ExpediaGroup#1019)

* [server] support batch requests

Add support for handling both individual GraphQL requests (current) as well as batch requests (new) that specify a list of `GraphQLRequest`s in their HTTP body. Single context is created for batch requests and each one of the requests has to provide valid response.

* fix example/ktor-server ktlint violations

[plugin] refactor Gradle tasks to use Worker API (ExpediaGroup#1002)

Updating all Gradle tasks to use Worker API that allows us to minimize the number of plugin dependencies through classpath isolation. Plugin has `compileOnly` dependencies on `graphql-kotlin` modules (`client-generator` which is renamed `plugin-core` module and `sdl-generator`). New `WorkAction`s will use classpath isolation with custom configuration that includes necessary dependencies to run the actions.

Updated build scan (from example gradle client): https://scans.gradle.com/s/znufum5lj75lg/build-dependencies

[build] update gpg key (ExpediaGroup#989)

[generator] additional test for nested optional input values (Expedia…

…Group#976)

See ExpediaGroup#954 for details