Further cache improvements (async cache key generation)

[MiniDigger]

Describe the feature

Additionally to #874, I have usecases for async cache key generation and null cache keys (that should lead to a cache bypass)

Basically, my caching key is generated by a 3rd party service, so my getKey method makes a network call (so returns a promise). Additionally, if that network call fails, I don't want the default cache key generation to happen, so my getKey method needs a way to tell nitro that.

what I would propose is adding an awaits here
https://github.com/unjs/nitro/blob/v2.0.0/src/runtime/cache.ts#L120
https://github.com/unjs/nitro/blob/v2.0.0/src/runtime/cache.ts#L161
and making this async
https://github.com/unjs/nitro/blob/v2.0.0/src/runtime/cache.ts#L160

how to handle the second part of my request I don't know yet. Maybe returning false from getKey and checking for that here and here?
https://github.com/unjs/nitro/blob/v2.0.0/src/runtime/cache.ts#L162
https://github.com/unjs/nitro/blob/v2.0.0/src/runtime/cache.ts#L120
(if key == false, return fn(...args) similar to https://github.com/unjs/nitro/pull/874/files#diff-b6cbd58c14e4265d5cee3c13fc5bdaff3df92a7958f2a6c12c4a471ab49efe27R121)

if that sounds like something you want, I can make that PR

Additional information

• Would you be willing to help implement this feature?

[pi0]

Async key support seems a good idea 👍🏼 By returning a falsy, i think fallback to default key is safer. We have explicit shouldByPassCache option now :)

[MiniDigger]

PR'd the first part, idk what to do with the second, maybe I need to rethink my logic a bit, but I basically want to handle the case where the getKey promise is rejected? its not too important to me rn, so am fine with this issue being closed by the PR if nobody has an idea.

[pi0]

Error handling would be good idea indeed however also applies to current sync support.

Thanks for PR!