Add utility helper to update infinite data

[paul-sachs]

This new API is very similar to createProtobufSafeUpdater, just designed to update and validate paginated data.

Fixes #517

[timostamm]

Is it really a good choice to grow this part of the API?

Here's a diff between using createProtobufSafeUpdater, and not using the function:

queryClient.setQueryData(
  createConnectQueryKey({
    schema: say,
    transport,
    input: {},
    cardinality: "finite",
  }),
- createProtobufSafeUpdater(say, (prev) => {
+ (prev: SayResponse | undefined) => {
    if (prev === undefined) {
      return undefined;
    }
    return create(SayResponseSchema, {
      sentence: prev.sentence + "x",
    });
- }),
+ },
);

It's certainly nice that the function enforces the correct return type, but it's still possible to pass in the wrong schema, or set the wrong cardinality for the key.

Wouldn't it be sufficient to document an example for infinite queries, such as:

queryClient.setQueryData(
  createConnectQueryKey({
    schema: say,
    transport,
    input: {},
    cardinality: "infinite",
  }),
  (prev: InfiniteData<SayResponse> | undefined) => {
    if (prev === undefined) {
      return undefined;
    }
    return {
      pageParams: prev.pageParams,
      pages: prev.pages.concat(
        // data in the cache is always a full message, not an init object
        create(SayResponseSchema, {
          sentence: "x",
        }),
      ),
    };
  },
);

[paul-sachs]

@timostamm this is fair, the API is a better fit inside a dedicated QueryClient that can enforce data matches. This was just a stepping stone to be able todeprecate both APIs but if we want to focus on getting a dedicated QueryClient out instead, which does a better job of exactly this thing, I can get down with that.

[paul-sachs]

Closing in favour of integrating into QueryClient #468