Possibility to define Apollo's fetchPolicy per request by using useAsyncQuery is MISSING

[awacode21]

Environment

• Operating System: Darwin
• Node Version: v18.19.1
• Nuxt Version: 3.12.2
• CLI Version: 3.12.0
• Nitro Version: 2.9.6
• Package Manager: [email protected]
• Builder: -
• User Config: hooks, typescript, css, postcss, build, components, devServer, devtools, vite, app, modules, pinia, apollo, routeRules, delayHydration, eslint, runtimeConfig, experimental, sourcemap
• Runtime Modules: @pinia/[email protected], @nuxtjs/[email protected], @vee-validate/[email protected], @nuxt/[email protected], [email protected]
• Build Modules: -

Describe the bug

The Nuxt Apollo module has the problem that you cannot specify an option for apollos fetchPolicy in the useAsyncQuery composable. There is the option cache (from Nuxts useAsyncData) as boolean, but this has been changed in this commit so that either the fetchPolicy from the nuxt config is used (if cache option is false) or cache-first is always used (if cache option is true). So if cache-first is set for all queries in the nuxt config, there is no option to change the policy to no-cache for just one query. It would only work the other way around, i.e. nuxt config no cache and then activate the cache as 'cache-first' by setting cache = true for a specific request.
Additionally this is still limited. Apollo graphql provides 6 different possible fetchPolicies, which are not covered here.
Currently we only have the option in nuxt config to set one fetchPolicy which is true then for all request, but the possibility to decide per request which fetchPolicy to use is completely missing here!!!! this is a big, big issue.

Expected behaviour

Correct would be if the useAsyncQuery composable would provide the possibility to set fetchPolicy per request. So you can decide on request basis which of the 6 possible fetchPolicies of apollo you want to use. The fetchPolicy from the nuxt config should only be a default setting if nothing else got set on the composable usage itself, it should not be the one and only rule for all requests of a project.

Reproduction

No response

Additional context

This problem resulted in several issues and PRs in the past, but it never got fixed properly:
Examples:
#348
#625
#467

Logs

No response

[awacode21]

@Diizzayy