[Fleet] Add caching on epr package queries

[juliaElastic]

Related to #125794

Caching on GET /api/fleet/epm/packages/<name>/<version> API is not implemented, because it fetches info from kibana saved objects, as well as epr.

When hitting the Settings page of an Integration, we are making the query to epr many times (seeing 20+ for one Settings page load). e.g. https://epr.elastic.co/search?package=system&prerelease=true&kibana.version=8.8.2
This is very inefficient and causes unnecessary load on epr.

We could use a library like node-fetch-cache to cache for a ttl of 10m (similarly to other /epm routes cache control headers).

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[juliaElastic]

We have changed the archive cache recently, so I'm not sure if this is still an issue.

[nchaulet]

@juliaElastic I am wondering if can implement some browser caching to avoid those requests use something like Last-Modified or an etag, using a in memory cache server side will increase our memory usage.

I was thinking we could a Last-Modified header like this:

1. first request Fleet set the Last-Modified header with the installation updated_at value
2. second request the browser will send the Last-Modified header
3. in server code we can check this Last-Modified against the installation and have a faster respond without querying the EPR

What do you think?

[juliaElastic]

Good idea, we could try first with Etag, as it seems Last-Modified is less accurate.
For integrations not installed, we could have another value used as an Etag.

[nchaulet]

I tried to play with the etag, but it seems a little harder than expected as the /api/fleet/epm/packages/<name>/<version> also fetch the latest available version (that is not very cachable)

It seems we reduced a lot the number of EPR queries needed on the details package for example for the nginx package

@juliaElastic I am wondering if we should just closed that issue

[juliaElastic]

Sounds good, I think we can close it.