Feat: Add Support for @defer Directive with Incremental Delivery

[amitksingh1490]

We need to support defer capability which is suggested in the spec here
https://github.com/graphql/graphql-wg/blob/main/rfcs/DeferStream.md

When the server recieves a defer directive on a fragment IO call to resolve that fragment should happen but for sending the initial response tailcall should not wait for the result of the that IO call and send the other results based on the spec.

Its possible that due to query planning that deferred call could move up as there was no dependency, even in that case even if this fragment IO succeeds before the other required IOs or fragment IO is cached still The spec should be followed and result should be sent in subsequent payloads.

Should work on both HTTP1 and HTTP2
For GraphQL communications built on top of HTTP, a natural and compatible technology to leverage is HTTP chunked encoding to implement a stream of responses for incremental delivery.

If client cancels the request before the deferred IO is completed the IO should be cancelled in that case

---

Description:

Implement support for the @defer directive in accordance with the [GraphQL Defer Stream RFC](https://github.com/graphql/graphql-wg/blob/main/rfcs/DeferStream.md). This feature allows servers to deliver GraphQL responses incrementally by deferring the resolution of certain fragments.

---

Requirements:

1. Deferred Fragment Resolution:

   • When the server receives a query containing the @defer directive, the resolution of the deferred fragment should occur asynchronously.
   • The server must not wait for the deferred fragment to resolve before sending the initial response. Fields and fragments not marked with @defer should be resolved and included in the initial payload.

2. Compliance with Query Planning:

   • Even if query planning moves the deferred fragment up (due to no dependencies) or caching, the server must still adhere to the specification:
     • Deferred results should always be sent as subsequent payloads.
     • The initial payload should only contain results that are not deferred.

3. Streaming via HTTP:

   • For GraphQL communications over HTTP, leverage chunked transfer encoding to stream incremental responses:
     • Ensure compatibility with both HTTP/1.1 and HTTP/2.
     • Responses should use the multi-part response format outlined in the RFC to deliver incremental updates.

4. Client-Driven Cancellation:

   • If the client cancels the request before the deferred fragment IO completes:
     • The server must cancel the ongoing IO operation to save resources.

---

Example:

Query:

query {
  user {
    id
    name
    ... @defer {
      profile {
        bio
        socialLinks
      }
    }
  }
}

Server Behavior:

• Initial Payload: Contains the id and name fields of the user.
• Deferred Payload: Contains the profile fragment, sent as a subsequent response.

---

Implementation Notes:

<>TODO<>

[github-actions]

Action required: Issue inactive for 30 days.
Status update or closure in 7 days.

[github-actions]

Issue closed after 7 days of inactivity.