RFC: Support subscriptionExchange API in @urql/exchange-persisted-fetch

[kitten]

Summary

See #2988

Currently, it's not possible to pass a persisted payload to a subscriptionExchange. We simply terminate persisted queries using @urql/core/internal's fetch internals.

That's because we can't alter the output of operations without guaranteeing a constant shape throughout. While it could be possible to provide a separate property on Operations for a "serialised" form of what's passed to GraphQL APIs, it likely makes more sense to extend @urql/exchange-persisted-fetch with a persistedSubscriptionExchange.

That's because any transport could in theory accept what an HTTP request body does, so we can extend this to a generic interface.

Proposed Solution

Add persistedSubscriptionExchange to @urql/exchange-persisted-fetch

NOTE: This may imply that we should rename persisted-fetch to something more generic;
either simply @urql/exchange-persisted or @urql/exchange-persisted-queries.

Another aforementioned solution here is to spread out the payloads of what we're sending across multiple exchanges. This currently isn't a preferred solution, imho, since the "persisted" exchange is unique in that it may "destroy" the query property on payloads.

Requirements

• Create a persistedSubscriptionExchange mirroring the subscriptionExchange in core
  • Expose shared utilities (see implementation of subscriptionExchange) in @urql/core/internal
• Share logic between persistedFetchExchange and persistedSubscriptionExchange to create the payload
• Other considerations for cleanup: Currently, the API of the exchange implies that it's supposed to be primarily used for subscription operations, which simply isn't always the case anymore.
  • Consider surface API clean ups (parameters to subscriptionExchange)
  • Optional: Consider renaming subscriptionExchange to transportExchange (?) while we're at it (we'd keep an alias of the old name)