using fetchPolicy/nextFetchPolicy across server/client rendering in client components

Our goal with apollo client is to configure the following behavior:

1. Always fetch data from network when a component mounts/remounts (to avoid stale data)
2. Allow using data from the cache while the network fetch occurs
3. Use data in cache for re-renders

We use the following watchQuery options which implements the above in a fully client-side rendered environment.

```
watchQuery: {
fetchPolicy: 'cache-and-network',
// We want to rely on the cache when a component re-renders (not remounts) rather
// than send a new network request on every render after a mutation that touched the cached object
// https://github.com/apollographql/apollo-client/issues/6760#issuecomment-668188727
nextFetchPolicy: 'cache-first',
errorPolicy: 'all',
},
```

However, now we're starting to incorporate SSR rendering of client components using `useSuspenseQuery`.

What I think should happen is that the SSR pass should use `fetchPolicy: 'cache-and-network'` and then once the client hydrates the first (and subsequent) render(s) would use `nextFetchPolicy` until the component is unmounted and remounted at which point we'd start back at `fetchPolicy`.

We observe in practice is a duplicate fetch for each query since one fetch occurs during SSR and the other during CSR. It looks like `fetchPolicy/nextFetchPolicy` application is not preserved across the server/client boundary. Is this intended behavior? Am I thinking about the implementation of `fetchPolicy/nextFetchPolicy` correctly? For full transparency I find the docs on fetchPolicy/nextFetchPolicy a bit confusing. It's not totally clear what constitutes an "execution" 🙈

As always, thanks for any help / thoughts you have!

Start with the useSuspenseQuery path across SSR and CSR hydration, focusing on the watchQuery fetchPolicy and nextFetchPolicy options described in the issue. Reproduce the duplicate query fetch and determine whether policy state should persist across the server/client boundary; done means the intended behavior and any required change are covered by a regression test.

Written by the indexing model from the issue text.