Call function (e.g. to update a materialized view) before query
<!-- Before opening an issue: if you use `npm` try running `yarn` instead; if
      you run `yarn`, please try running `npx yarn-deduplicate && yarn`. -->

<!-- You can also chat with us on Discord: http://discord.gg/graphile -->

### Summary

Is it possible to make PostGraphile call a volatile function to update some tables or materialized views before it queries other tables?

<!-- Please detail the issue you'd like to discuss. -->

### Additional context

The data I'm trying to query needs to be filtered depending on query parameters. E.g. all my tables have a `version` column, and all queries have one `maxVersion` parameter, which mean that all nodes should be automatically filtered to exclude all rows with `version > maxVersion` (and then deduplicated by `id` taking the row with the biggest `version`).

Initially I implemented it as SETOF-returning functions, but that turned out to be too slow because PostgreSQL can't inline them very well and does not materialize their output, so e.g. I think if the same table is referenced multiple times then it is computed multiple times.

Then I tried to create "cached" versions of these tables holding the result after filtering, and pre-populate the caches as part of the query, i.e. there is a root `data { ... }` node which maps to a function which populates the cache tables. This is much faster but isn't working very well because the cache is populated in parallel to other parts of the query which read from the same tables, so for call N we get the results for call N-1.

So I think I need a way to create a root `data` node which calls a volatile function which populates the cache, and that must happen before any `SELECT` from any cache table starts running... but if there's another way to generally do parameterized filtering of all tables efficiently then that will work too.

<!-- Please provide additional context such as environment versions (including
      operating system, Node, PostgreSQL, Redis, etc. as relevant), software
      versions (from `yarn.lock`) or similar, plugins in use, database schema
      if relevant, bundler (if any). -->
