feat: add support for streaming cache responses

[lukekarrys]

🔗 Linked issue

#1894

❓ Type of change

• 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This is one possible way to support binary responses in cachedEventHandler. When stream: true is set on the cache options, the response body will not be read at all and will instead be teed with one stream sent to setItemRaw() and the other returned as the response.

This can be useful for text responses as well when proxying (such as large JSON data) because the response does not need to be read into memory. It can be streamed directly to the client while writing to the cache does not block the response.

When using the stream: true option it will require special handling of the stream in the setItemRaw method of any storage adapter. So I think this is an advanced use-case and doesn't automatically fix #1894.

I experimented with another fix that would use res.arrayBuffer() and convert it to an Uint8Array so the response could still be serialized as JSON. But for my use-case (tar files that were potentially 100s of MB) it was too slow. I'd be happy to amend this PR to support that as well.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[vercel]

@lukekarrys is attempting to deploy a commit to the Nitro Team on Vercel.

A member of the Team first needs to authorize it.