feat: CompletableFuture in FederatedTypeResolver, standardize entities resolver with other subgraph implementations

[samuelAndalon]

📝 Description

With the idea of proving support for returning a CompletableFuture in FederatedTypeResolver
and match other subgraphs implementations a new sealed interface is added

sealed interface FederatedTypeResolver {
    val typeName: String
}

this will be the basic interface of 2 interfaces

1. The currently supported FederatedTypeResolver is renamed to FederatedTypeSuspendResolver, with support of suspendable function to be executed in a coroutine

interface FederatedTypeSuspendResolver<out T> : TypeResolver {
    override val typeName: String
    suspend fun resolve(
      environment: DataFetchingEnvironment, 
      representation: Map<String, Any>
    ): T?
}

2. Added a new interface called FederatedTypePromiseResolver that will provide support to return a CompletableFuture allowing compatibility with a DataLoader

interface FederatedTypePromiseResolver<T> : TypeResolver {
    fun resolve(
      environment: DataFetchingEnvironment, 
      representation: Map<String, Any>
    ): CompletableFuture<T?>
}

Clients will have the freedom to decided which interface to use for their resolvers and graphql-kotlin will be smart enough to decide how to execute them.

The execution logic will be capable of executing suspend resolvers or promise resolvers concurrently, specially useful if you have support for data loaders for only certain entities

example representations for multiple types, request to _entities field

UserResolver implementing FederatedTypeResolver
PromiseResolver implementing FederatedTypePromiseResolver

[
  { "__typename": "User", "userId": 123 },
  { "__typename": "User", "userId": 456 },
  { "__typename": "Author", "authorId": 1 },
  { "__typename": "Author", "authorId": 2 },
]

This is going to be a breaking change as it changes the signature of the current FederatedTypeResolver by simplifying the logic, before it was providing a list of representations, and now it will provide a representation (internally graphql-kotlin will ensure the ordering).

All this with the effort of matching other subgraph implementations like Apollo Server
https://www.apollographql.com/docs/federation/api/apollo-subgraph/#__resolvereference

graphql-kotlin

object : FederatedTypeSuspendResolver<User> {
  override val typeName: String = "User"
    suspend fun resolve(
      environment: DataFetchingEnvironment, 
      representation: Map<String, Any>
    ): User? {
      // representation will always have at least the `id` and the `__typename` here
    }
}
object : FederatedTypePromiseResolver<User> {
  override val typeName: String = "User"
    fun resolve(
      environment: DataFetchingEnvironment, 
      representation: Map<String, Any>
    ): CompletableFuture<User?> {
      // representation will always have at least the `id` and the `__typename` here
    }
}

apollo-server

const resolvers = {
  User: {
    __resolveReference(representation, env) {
      // representation will always have at least the `id` and the `__typename` here
    }
  }
};

A couple of tests simulating async operations and delays were added to ensure ordering is properly maintained

🔗 Related Issues

#1506

[dariuszkuc]

based on the code the type is actually

type Author @extends @key(fields: "authorId") {
  authorId: Int! @external
  name: String: @external

If both fields are external -> should it be @key(fields: "authorId", resolvable: false)? or should there be at least a single local field?

[dariuszkuc]

should else also keep track of errors in the list?