[FEATURE] Use a longer than `max-cache` value for cached packuments

[ruyadorno]

Currently, the maximum cache value defined by the registry (under a minute? note: pending confirmation of the actual value) for packuments makes it impossible for actual human users of the cli to benefit from that caching in order to speed up further installs.

Even more sneaky is that benchmarks are perfectly capable of benefiting from that since they're going to be running within that very limited time frame, skewing our vision of the performance of the current implementation.

We should define an arbitrary time to invalidate packument entries in our cache, long-enough for users to be able to benefit from it. That probably means we'll also need an option to manually invalidate entries but the default install experience should be able to benefit from that larger window of time in order to maximize the number of packuments retrieved from our internal cache.

[isaacs]

Packuments are cached (and not re-validated) for 5 minutes. After those 5 minutes are up, they are revalidated with the ETag, and so get a 304 response if there's no update, which is much faster than downloading the whole thing again.

Failing to re-validate for longer than 5 minutes is likely a bad idea, since it invites the annoying behavior where you publish something, and can't immediately install it. (Ie, every time I have to npm i whatever --cache=x; rm -rf x just to get something that I know is there, because I just put it there.)

Before we start caching for longer than the recommended time in the response header, we should benchmark the actual situation that we think will be improved, for example by explicitly setting the cache age to longer than 5 minutes and re-validating, to determine if it's worth the hazard.

[isaacs]

This is effectively solved by the stale-while-revalidate-factor config.