feat(apollo-mock-client): support async resolvers

[pavelglac]

Summary

• Update resolveMostRecentOperation to support async resolvers by awaiting the resolver return value
• Update MockFunctions interface to accept ExecutionResult | Promise<ExecutionResult> as resolver return type

Motivation

Apollo Client v3.8.0 introduced PR #10229 which added a previousResult?.networkStatus !== result.networkStatus guard to handleErrorOrCompleted in useQuery. This guard prevents onCompleted from firing on cache writes, but it interacts badly with synchronous mock resolution.

The issue is that Apollo's ObservableQuery.getCurrentResult() reads queryInfo.networkStatus (a shared mutable property set directly by markReady()) and this.last (updated later via reportResult() through zen-observable's notification chain). When mock resolution happens synchronously, markReady() sets networkStatus=ready before zen-observable delivers the data through reportResult(). This causes getCurrentResult() to return an inconsistent intermediate state — networkStatus=ready but no data — which consumes the networkStatus transition. By the time data arrives, the guard sees no networkStatus change and blocks onCompleted.

This is a known Apollo bug acknowledged by the Apollo team (#12334, #12480) that will only be fixed in Apollo Client 4.0.

By supporting async resolvers, tests can introduce a microtask boundary (async (operation) => { ... }) that flushes pending zen-observable subscription microtasks before delivering data — matching production timing where network responses are inherently async.