Subscription system timing issues

Currently, GraphQL-Ruby's subscriptions are prone to two kinds of timing problems:

1. With Pusher and Ably, there's a time when the subscription is saved to the database (via write_subscription) but the client isn't actually listening yet because it hasn't picked up the HTTP response and opened the connection to the pubsub provider. If events are triggered during this time, they'll be sent to nowhere 😢
2. There's no way for a subscription field to do anything after it has registered itself in the database. For example, if a field wants to begin an async process knowing that the result of that process will be sent to the client, it can't be perfectly done. There's no place to start that process after write_subscription is called... and even if there was, you couldn't be sure that the client would actually receive the result because of the first problem.

Problem 2 actually seems easy to fix: add an after_subscribe hook and call it after write_subscription. But again, the usefulness here is marginal because of Problem 1.

Problem 1 seems hard to fix. ActionCable has the best chance of it, since the pubsub connection is happening right there on the application server.

With Ably it might be doable using "channel history," but it would mean updating the system to send messages to Ably even when nobody is listening (yet). Pusher has no built-in support for this, their docs recommend fetching data from the server: https://pusher.com/blog/how-to-add-message-history-to-your-pusher-apps/#message-history. In that case, we'd need a dedicated persistence system (Redis streams?).

Start by reading the subscription flow around write_subscription and the proposed after_subscribe hook. Compare how ActionCable, Pusher, and Ably establish pubsub connections, then determine how missed events could be handled. Done means the timing gaps are addressed with a defined persistence or delivery strategy and covered by relevant subscription tests.