Add an API endpoint to trigger cache refresh

[soloradish]

Scenario:
We host a considerably large repository and have disabled the cache for immediate response. This has introduced a noticeable lag (1-3 seconds) when retrieving charts. If there were an API to trigger a cache refresh, we could enable caching with specified intervals. Then, after pushing a new chart, we could call this API to refresh the cache. This approach would allow immediate access to the new version and reduce the lag caused by a full scan.

[manysuq]

This keeps coming up (#654, #545, and several issues where the only workaround is lowering --cache-interval), so I'd like to take a shot at implementing it. Rough design, feedback welcome before I open a PR:

Endpoint: POST /api/:repo/cache/refresh, scoped to a single tenant. In multi-tenant setups refreshing every tenant is usually unnecessary and expensive; a repo-scoped call is the precise fix for "storage changed under me, index is stale".

Auth/flags: gated behind the existing APIEnabled like the other /api routes, with cm_auth.PushAction. Mutating the served index is a push-level operation, so existing basic-auth setups keep working and no new flag is needed, unless you'd prefer one.

Behavior: reuses the same machinery the --cache-interval rebuild uses (rebuildIndexForTenant path: init cache entry, fetch storage list, diff, regenerate), but made synchronous for the request and returning errors to the client instead of only logging them: 200 {"refreshed": true} on success, 4xx/5xx otherwise. The interval-based background rebuild stays exactly as it is, so this is purely additive.

If that shape sounds right, I'll open the PR with tests.

[scbizu]

@manysuq thanks for catching up this issue , I have the same idea as you before . But for a server , per my understanding , if we opened this endpoint , it means everyone can reach this endpoint to trigger the index update , which will lock the tenant , and make the server out-of-control.

In this favor , the --cache-interval is configurable and the server admin can adjust this value per their cluster size . But the case you mentioned is a very good proposal , we can add this endpoint to the /admin/cache/refresh maybe and make the /admin router only works for the server admin through some role verification policy .

Any thoughts about that ?

Again , thanks for your PR ~